Thats 15% of a badly sampled group of 46 users. No matter how you look at it, it is neither "statistically significant" (as it doesnt really qualify as a good sampling) nor is it a major percentage.
Matters not. There are many other folks who have done similar studies with similar results. That was just the first one I could dig up in a Google search.
You may cut and paste several thousand times while attempting to sort out a music library...
Blech. That's pretty horrible. Can't this interface support multiple windows, one per folder, and let you drag files to where they need to go? Cutting and pasting files is an okay interface for the occasional move, but it's clumsy as heck if you're doing it over and over.
... but to say that explorer is supposed to be smart enough to figure out how to arrange my files the way I want is ridiculous.
I didn't intend that to include user actions that actually change data. By that same logical stretch, you might think that I would expect a word processor to automatically type the "e" key because I do it so often. Clearly, that's not a rational interpretation of what I said....
In that paragraph, I was referring to repetitive actions that are exactly the same every time, done in exactly the same way, achieving the same results in the same context. The most common example of this is actions that alter the UI behavior, like window size and position, column lists, sort order, etc. The granularity at which such information should be stored varies depending on the information in question. For example, I'd expect window sort order to stay the same every time I go back to a specific folder, but I'd expect the shown/hidden columns setting to be the same every time I open a browser window in a list view.
Prices are only high on eBay because there are a handful of people who really want one of these things, and there's a very limited supply available. I doubt they would sell at $325 on the open market. It's too close to the used iPad price for first-generation devices of similar size, and the iPad actually has a large and vibrant developer community producing apps for it....
At $100, I'd consider buying one just to mess around with it, run Linux on it, maybe use it as a MythTV front end or something. I know it would be completely unsupported, but at a hundred bucks, it's a small enough amount of money that I wouldn't be too horrified if I wasn't able to do anything interesting with it besides sell it on eBay at a loss in a year or two.
At $200, you're approaching two-thirds the price of a used first-generation iPad, which (unlike the TouchPad) is likely to still be supported by the manufacturer with OS updates in the future.
There's also a pretty significant difference in perception of cost between $100 and $200. Psychologically, $200 seems expensive, whereas I spend $100 on books at Borders last weekend.
Dude, unless something has changed since the TSA loosened the restrictions in 2007, you can bring a cigarette lighter on a plane. I'm no chemist, but I'm pretty certain that those can start a fire, and they aren't even banned....
That's pretty easy. You are less free because you cannot deny freedom to others even if they want you to do so, and even if denying that freedom is in their own best interest. For example, the public has a right to safety. You cannot effectively protect safety without denying freedom to at least a limited degree. It can't be done. As Oliver Wendell Holmes put it, the right to swing my fist ends where the other man's nose begins.
To ground this principle firmly in the software space, the GPL forbids you from running the code on hardware that requires mandatory code signing. To many users, mandatory code signing is a security feature. It ensures that even if someone compromises their device, attack code cannot run. Thus, this is an example of a case where the other person asks to have some freedoms denied in exchange for greater safety. It is a fundamental right of that person to make such a request, regardless of whether you happen to agree with it. (It is not a right to force that decision on others, but nobody is forcing anyone to buy a locked-down device.)
The problem comes when you are a developer who wants to build a version of a GPLed application for such a device. Because doing so would allow others to place restrictions on the user's right to modify the code, albeit indirectly, you are not allowed to distribute a compiled, signed binary for such a device. As a result, everyone, including the end users, can no longer obtain the software because you are not allowed to build and distribute it.
In effect, what we have here is an arbitrary, theoretical freedom that fundamentally cannot be protected without destroying a very real-world freedom—the ability to run that piece of software on a piece of hardware—solely because the hardware in question strikes a different balance between two theoretical rights (freedom to code vs. privacy of the user's data).
The funny thing about folks saying that they think Apple might win on this one is that Apple has supported mounting disk images since System 7 (1991), and ISO images for... well, a long time. Is this article actually saying that Windows is almost two decades behind the Mac on such a basic end-user feature? No wonder users are flocking to the Mac.... And judging by the comment about the ribbon bar, I'm guessing Windows will also require you to click a special button to do something that in any sane universe should just require a double-click....
As for the walled garden thing, that works well on new devices like tablets because there isn't an established market, so people don't have any preconceived expectations. I don't see that model completely displacing the established market in the computer space any time soon. There are just too many things that people use computers for that just don't fit that distribution model, from apps with plug-ins to command-line tools.
Most users don't even understand what that little arrow next to a toolbar button means, they don't realize it means there are more options.
That doesn't mean it's a bad interface. It's a highly discoverable interface. The first time they click it, they see the menu pop up. Now they know that there are more options. The hard part is naming the button so that they understand what options are likely to be in it. Assuming you choose which options to group in this way correctly, even this aspect should not be all that hard. If it is, the mistake is not in using a button with a menu, but rather in your naming and/or grouping. (Okay, in extreme cases, this could mean that using it was a mistake if the right number of things to group together happened to be "none of them", but you know what I mean.)
By removing the group labels, you add confusion as to why things are grouped the way they are, which makes it harder to cognitively remember them.
In my experience, if you need labels on groups of buttons, it generally means that you didn't pick good enough labels or icons for the buttons within the group. Things that are conceptually similar should have names that sound conceptually similar, and their icons should be visually distinct such that even those dividers are unnecessary, much less named labels on groups of icons.
Further, if those labels are useful, that means that the user doesn't actually understand what those buttons do, and this typically indicates that the user in question should not have been exposed to those controls in the first place.
Rarely used features are more important to make visible, not less visible.. because people don't know they're there otherwise.
That's wrong at a fairly fundamental level. The goal of a user interface is not to show off every feature of an app. The goal of a user interface is to make it as easy as possible for users to discover the things they need in order to do their job. In other words, its main purpose is to get out of the way of the user. If a user interface is trying to highlight obscure features that the user probably will not need, the UI is an epic fail. Finding rarely used features is what help systems are for, not to mention the ability to search through menus by words in the name. (Or is that just a Mac OS X thing?)
Remember, the ribbon is not for power users. It's for regular people, just as the Vista and 7 UI's were. Power users use keyboard shorcuts and context menus.
If it's for regular users, then the ribbon for something like this should have roughly four buttons:
Cut
Copy
Paste
Share
At most, add one more button for "preferences". That's it. Everything else there is unnecessary and confusing for regular people. What I'm seeing here is not designed for ordinary users. It is designed to try to show those ordinary users everything that power users might potentially want to do, which quite frankly is just about the worst offense you can possibly commit as a UI designer short of making all your controls hot pink on neon green....
Put another way, I think this blog post sums it all up nicely.
You're basically trying to bring back the menu, turning the most common operations into multiple-click, semi-hidden operations. Wrong.
Not at all. I'm talking about a menu button for nearly identical choices (multiple variations of "copy", for example). It's a button that when you click it, a menu pops up. Choosing a selection from such a menu takes exactly the same number of clicks (1) as it does to choose that selection from individual buttons, yet reduces clutter in the user interface. Further, if that reduction in clutter prevented you from having to change tabs to get to the option, it takes two fewer clicks than having it as a separate button.
In fact, nearly every single suggestion I made provably does not add any clicks even in the worst case, and in most cases, requires fewer clicks to do the same thing.
Removing 'Add Columns' gains nothing, that space wouldn't be doing anything else. It's not used a lot, but when it is, it's nice to have it there.
It's a lot easier to click "choose columns" and click checkboxes by the ones you want in a sheet, then dismiss the sheet. Assuming that you typically stay on the main tab, then in the ribbon design, it takes one click to get to the View tab, a second click to choose the column to add or remove, plus a third click to get back to the main tab.
It similarly takes three clicks to do it with a sheet, but you get the nice, clean UI of getting to see all of the options all at once in a neatly laid out grid, which opens up the possibility for showing far more columns than are feasible in a linear list. It also means that it's a lot less clumsy to add or hide more than one column at a time.
A one-click auto-size is useful, this is pointless complaining.
The default behavior should be to auto-size the columns that are most likely to be relevant (the name being the obvious one), use ellipses in the middle of names when that isn't possible, and scale the rest. 99.99% of the time, that's what you want, and the rest of the time, auto-size isn't going to work any better than changing the window size. In effect, an auto-size button is a "fix the brokenness" button. Good UI design should not require such hacks.
The point of the ribbon was that they were trying to be innovative and change the way we do things. We got to "tabbed controls" by "violating the single document per window" paradigm. Yet noone seems to mind that today.
Actually, statistically, a sizable percentage of users never open a second tab, so I wouldn't go so far as to say nobody minds. This is true across all browsers, BTW. (That particular study used a small sample size that didn't demonstrate this, but there are other studies on the subject.) Having multiple things in a single window is really not a good fit for most people's mental models.
Many folks use tabs because they find it handy to see the names of pages rather than cycling through the windows until they get to the right one. In the end, the experience doesn't really differ that much, though, except for users who do everything with a mouse. Power-users who are used to keyboard navigation usually don't really see the benefit to tabs over windows, and naive users don't understand how tabs work at all. So they basically only provide a tangible benefit for people in a fairly narrow band in the middle somewhere—people who are both experienced computer users and who have not yet discovered the joys of carpal tunnel syndrome from mousing too much....
...do you have usability studies that you can reference regarding the labels "doing nothing"?
Do I have usability studies on a prerelease mock-up of an interface? Of course not.
Is it obvious that putting "Zip" (compress) under a "Send" label is remarkably confusing? Of course.
Don't get me wrong, labels on individual buttons are very useful. Labels on segmented controls and similar are also useful. Labels on groups of loosely related buttons... not so much.
... or that they did NOT use the data in their design...
Probably this, but it's also possible that some other aspect of the experience is broken, so people do tasks frequently that they shouldn't have to do frequently. In general, if you're doing the same thing over and over, that's usually an indication that the application is failing to store some preference that it should be storing. I don't personally run Windows, so I can't say which.
The overarching problem here is that you shouldn't need nearly that many controls to do 90% of your work. If you have more than a dozen buttons, there's something very fundamentally wrong, and it's probably not just the buttons, but rather the entire way you're looking at the problem that you are trying to solve....
How is haphazardly mixing multiple sizes of buttons with complex scrolling controls and text an improvement in UI design? My gosh, have you actually looked at this thing?
Putting commonly used features within easy reach is inarguably good UI. Making it customizable so that the definition of "commonly used" can be modified by the user, however, is also inarguably good UI. Doing this, by definition, necessitates something approaching standardization of icon sizes, layouts, etc. Instead, what we have here looks like a Jackson Pollock painting.
Let's look at what's wrong with this UI design, point by point:
Tabbed navigation incorrectly used to select between banks of controls
Tabbed navigation is assumed to affect the contents of the screen as a whole. It is a fundamental abuse of the metaphor to use it to choose between banks of controls.
The need for tabs is a clear indication that you are bringing way too many controls to the forefront of the user's attention.
Most users won't notice the tabs, and will be confused if they accidentally click on one because they won't know how to get back to the controls that they're used to. They will, in turn, file bugs or call tech support.
Tabbed navigation shares a row with other information
I'm guessing that the blob called "File" is not part of the navigation tabs, but it appears to be. While it might seem convenient to reduce the vertical spacing by placing unrelated information in a tab bar, it's extremely confusing. It looks to me like two different things are selected in a single tab bar, which is just plain wrong.
Unhelpful grouping labels
Although conceptual grouping of icons can be useful in terns of keeping related things together, it is generally not useful to label those groups. This wastes valuable vertical screen real estate and adds nothing to the user's understanding. Yes, in some way, burning a file to disc is conceptually similar to emailing it to someone, but a label called "send" doesn't add meaning, and is actually a bit confusing.
Inconsistent levels of detail, and non-independent controls
There are wildly different levels of detail between different features in this UI. You have simple tasks like "Print" that presumably open their own dialog boxes, and then you have things like sharing preferences in which lots of detail is crammed into a single section of the ribbon bar for no good reason. "Sharing options" could be a single icon in a button bar that brings up a modal sheet or dialog box, and no convenience would be lost.
In general, UI elements should be independent unless you are in a dialog box or sheet. Clicking an item in a button bar or similar should cause either an action to occur or a dialog box to appear for getting more information. Items in button bars should absolutely not depend on other items in the bar for their behavior.
Minor variations have separate buttons instead of a pop-up menu
If there are several UI elements that conceptually do the same thing, then they should be combined into a single menu item with a pop-up menu to choose which specific variant action should be performed.
Example 1: "Send" button: display a pop-up for email, burning, etc. (Note: compressing a file is *not* an equivalent action, and should *not* be listed with the rest of those.)
Example 2: "Clipboard" button: for all of the various cut, copy, and paste options, show a hierarchical menu that pops up when you click the clipboard/pasteboard button.
By making those two changes, you've turned basically two ribbon bar tabs into two or three buttons with a couple of simple pop-up menus and a simple modal sheet.
Rarely used UI options are artificially elevated
Most people don't add or remove columns in their views regularly. That's the sort of thing that you pretty much do once when you first get a computer, assuming
Alternatively, we could confuse things even more and have "day zones" instead of "time zones". You know, define the day to be whatever day it was when the sun rose.:-)
No big deal. Just choose some time zone where nobody lives as the standard world time. That way, 2200 hours isn't sunset for very many people. Problem solved. GMT-9 and GMT-10 are pretty good candidates.
I'm not saying it couldn't have made the transition. I've only seen a few tiny fragments of the Copland code base (that were ported to MkLinux), but what I saw looked like it would be reasonably portable.
My point was that by the time Apple acquired NeXT, it was already running on both PowerPC and Intel, which gave them a huge head start on the Intel transition just a few years later. I'm not sure when or if they ever stopped maintaining x86 support, but the last Darwin OS binary release in 2002 still contained Intel bits. I'd expect a big difference in effort between porting even a well-designed, highly portable OS from scratch and cleaning up an OS port that had been abandoned at most a couple of years earlier....
Would Copland have saved the day if it was released?
Definitely not. Copland was an interesting piece of software, and certainly much more modern than the 8 nanokernel (and it might even have been more modern than parts of Mac OS X, even—I'm not really sure), but the OS itself is not the whole story. In fact, it's arguably the least important part of the story.
Mac OS X wasn't just a replacement for Mac OS. It was also a usable UNIX. Copland certainly wouldn't have drawn the Linux/UNIX crowd the way NeXT did, and I think that had a real impact on the perception of Apple in the enterprise.
This, in turn, drove the intense popularity of Apple's laptops among the geek crowd (when other manufacturers' laptops weren't doing nearly as well). In an era when Apple was only three or four percent of the market, you could walk into a UNIX/Linux conference and half of the laptops would be Macs. Why? Because geeks wanted a usable laptop running some sort of UNIX variant, and running a laptop in Linux generally sucked at the time.
That popularity, in turn, caused all those geeks to recommend these things to their friends and families, which played a significant part in the rapid decline of desktop computing in favor of mobile computing in the first part of the last decade. The rapid shift towards laptops, in turn, was the reason Apple gave up on PowerPC and transitioned to Intel hardware—a transition that made Apple's computers immensely more popular almost overnight. How much of this was actually driven by Mac OS X being UNIX, I couldn't begin to guess, but I'm certain it was nonzero.
Also, NeXT brought with it functioning code for i386, and a functional set of developer tools (the GNU toolchain). The Intel transition would have been a lot harder with Copland, not to mention the whole ARM thing on iOS. Can you imagine if Apple were building iOS using CodeWarrior?
Finally, NeXT brought with it a lot of new blood. Apple doesn't usually acquire companies for technology. It acquires companies because it wants their employees. From what I hear from people who worked at Apple in that era, the NeXT merger created all sorts of culture clash initially, but in the end, it resulted in a much stronger company than either company could have become on its own.
And, of course, the merger brought back Steve Jobs. You can argue all you want about whether Steve actually made decisions that no one else could have or would have made, but ultimately that's not what matters. What matters is that one of the guys who founded the company was back at the helm. Psychologically speaking, I think that did more to get Apple back on its feet than anything else, including the NeXT merger, including any single decision that Steve made, including even the advent of the iPhone.
If it requires several thousand dollars in custom hardware, it's not likely to be happening in very many places. By contrast, any jackass with a standard issue laptop can snoop open Wi-Fi.
So yeah, GSM might be sniffable, but it's still statistically a few orders of magnitude less likely to be sniffed than unencrypted Wi-Fi.
Early horseless carriages were quite literally horseless carriages in every way. They looked like a carriage, they drove on the same roads as a carriage, etc. About the only differences were the lack of hardware to attach to a horse, which is kind of expected given that they were horseless, and different controls for driving the things.
I would therefore similarly expect a flying car to be a flying car, with the same functionality as a car, but with
different controls and the ability to fly.
I think if such tampering had occurred, there would be loads of evidence of it, particularly given that ancient copies of those texts still exist and are regularly studied.
Religion is not the symptom, but the wrong remedy. That's like saying "I've got cancer and one of the symptoms is chiropractors."
Although you may not agree with the remedy, much like chiropractic care for back pain, it can be an effective treatment for some types of problems. Many religious laws solved some fundamental problem (which may or may not still be a problem today).
For example, many of the dietary laws in Jewish and Muslim religion are believed to have been written to prevent certain types of food-borne illness. Mixing meat with dairy, if not done correctly, often results in undercooked meat. Eating pork results in greater contamination of the water supply because pigs require so much water that they tend to be farmed close to river. And so on.
For another example, many of the religious laws on sex stem from a fundamentally sound, albeit primitive, understanding of genetics. Having sex with close family members tends to result in all sorts of recessive traits becoming much more common, including a number of harmful mutations.
Heck, even prohibitions against wearing two kinds of clothing are useful for preventing static electricity buildup, which in a primitive society, could be misinterpreted as punishment from God, and could cause all sorts of really stupid mistakes.
I think the more interesting question is this: many of these religious laws suggest an understanding of medicine that is way beyond the understanding of the people who wrote them. Was this dumb luck, or is it the hand of God working among us? (Or, alternatively, did we get visited by aliens, if you'd prefer?)
First, people want simplified user interfaces on tablet-based devices because the hardware design (touching the actual screen) cannot handle more complex user interfaces. I'm not convinced that dumbing down the desktop to look like mobile devices is a win for anyone. Different devices are best served by different interfaces.
Second, for the people who want simplified UIs, there are already plenty of cheap or free apps out there that provide basic drawing (or, more commonly, basic photo cropping, scaling, and color correction, which turns out to be what 99% of novice graphics work entails). For GIMP to be useful, it needs to focus more on the underserved high end, not the thoroughly served low end.
A streamlined interface for newbies certainly isn't a bad idea for tripling the newbie traffic on the help mailing lists, if that's your goal, but it benefits few current GIMP users, whereas fixing the flaws in the existing UI would help current users and would make it more attractive to (moderately advanced) new users as well.
A flying car must, by definition, be A. flying, and B. a car. Try to drive one of those airplanes on the highway, and you'll quickly discover why airplanes are not flying cars. Flying machines, sure, but not flying cars.
A helicopter is a lot closer to a flying car than any airplane, or at least it behaves a lot more like a car in that it can sit still without falling from the sky, requires a relatively small landing area, etc.
The Digital Cameras and Camcorders need to come with bluetooth as standard, even the cheapest throw-away models.
For what? Viewing 320x240 thumbnails of the actual video data? You do know that the maximum data throughput of even EDR Bluetooth is only 2.1 megabits per second, right? And that typical AVCHD camcorders run at about 12 megabits per second? And that DV or HDV video is 25 megabits per second (or 50 megabits per second in some variants)?
Even Wi-Fi would work only if the two devices are close together and if no other devices are clogging the spectrum. Wireless data transfer has come a long way, but it is still nowhere near the point where it makes sense to use it as a primary means of connecting video gear. We need speeds that are at least an order of magnitude faster.
Agreed. It's slow, buggy, and it crashes browsers and/or browser helpers with such regularity that one can safely assume that the mere existence of Flash on your computer or device poses a security hole so big you could drive a truck through it.
Flash also leads people to create overly complex web site designs that don't work well over slow connections (e.g. EDGE, 3G, etc.) and waste tons of bandwidth that could cost customers actual money on metered networks (Comcast, AT&T DSL/U-Verse, pretty much all cellular services, and many others). Add to that all the stupid banner ads and other such nonsense that uses Flash for no good reason, and it is really a bandwidth pig.
Finally, Flash is inherently fundamentally incompatible with small devices like phones because of its CPU overhead. If I play a Flash game on my laptop, I can run the battery down in about an hour and a half. Doing normal work, my laptop lasts six hours. Scale that to a phone, and you can safely assume that if every web page used Flash, your smartphones would have to be recharged several times a day just from doing light web browsing.
So yeah, it's a feature. As much as I'd like the option of installing Flash on my iPhone (in a *separate* web browser that only gets used for the occasional site that require it), I'm really glad it doesn't come with it installed by default, and given the choice between no Flash at all and built-in Flash, I'd pick no Flash in a heartbeat.
Agreed. Calling it 16-bit color is just plain abusing the terminology. The correct term is "16-bit channels", not "16-bit color". Alternatively, one can call it "48-bit color".
Slashdot Mirror
Matters not. There are many other folks who have done similar studies with similar results. That was just the first one I could dig up in a Google search.
Blech. That's pretty horrible. Can't this interface support multiple windows, one per folder, and let you drag files to where they need to go? Cutting and pasting files is an okay interface for the occasional move, but it's clumsy as heck if you're doing it over and over.
I didn't intend that to include user actions that actually change data. By that same logical stretch, you might think that I would expect a word processor to automatically type the "e" key because I do it so often. Clearly, that's not a rational interpretation of what I said....
In that paragraph, I was referring to repetitive actions that are exactly the same every time, done in exactly the same way, achieving the same results in the same context. The most common example of this is actions that alter the UI behavior, like window size and position, column lists, sort order, etc. The granularity at which such information should be stored varies depending on the information in question. For example, I'd expect window sort order to stay the same every time I go back to a specific folder, but I'd expect the shown/hidden columns setting to be the same every time I open a browser window in a list view.
Prices are only high on eBay because there are a handful of people who really want one of these things, and there's a very limited supply available. I doubt they would sell at $325 on the open market. It's too close to the used iPad price for first-generation devices of similar size, and the iPad actually has a large and vibrant developer community producing apps for it....
Pass.
At $100, I'd consider buying one just to mess around with it, run Linux on it, maybe use it as a MythTV front end or something. I know it would be completely unsupported, but at a hundred bucks, it's a small enough amount of money that I wouldn't be too horrified if I wasn't able to do anything interesting with it besides sell it on eBay at a loss in a year or two.
At $200, you're approaching two-thirds the price of a used first-generation iPad, which (unlike the TouchPad) is likely to still be supported by the manufacturer with OS updates in the future.
There's also a pretty significant difference in perception of cost between $100 and $200. Psychologically, $200 seems expensive, whereas I spend $100 on books at Borders last weekend.
Dude, unless something has changed since the TSA loosened the restrictions in 2007, you can bring a cigarette lighter on a plane. I'm no chemist, but I'm pretty certain that those can start a fire, and they aren't even banned....
That's pretty easy. You are less free because you cannot deny freedom to others even if they want you to do so, and even if denying that freedom is in their own best interest. For example, the public has a right to safety. You cannot effectively protect safety without denying freedom to at least a limited degree. It can't be done. As Oliver Wendell Holmes put it, the right to swing my fist ends where the other man's nose begins.
To ground this principle firmly in the software space, the GPL forbids you from running the code on hardware that requires mandatory code signing. To many users, mandatory code signing is a security feature. It ensures that even if someone compromises their device, attack code cannot run. Thus, this is an example of a case where the other person asks to have some freedoms denied in exchange for greater safety. It is a fundamental right of that person to make such a request, regardless of whether you happen to agree with it. (It is not a right to force that decision on others, but nobody is forcing anyone to buy a locked-down device.)
The problem comes when you are a developer who wants to build a version of a GPLed application for such a device. Because doing so would allow others to place restrictions on the user's right to modify the code, albeit indirectly, you are not allowed to distribute a compiled, signed binary for such a device. As a result, everyone, including the end users, can no longer obtain the software because you are not allowed to build and distribute it.
In effect, what we have here is an arbitrary, theoretical freedom that fundamentally cannot be protected without destroying a very real-world freedom—the ability to run that piece of software on a piece of hardware—solely because the hardware in question strikes a different balance between two theoretical rights (freedom to code vs. privacy of the user's data).
The funny thing about folks saying that they think Apple might win on this one is that Apple has supported mounting disk images since System 7 (1991), and ISO images for... well, a long time. Is this article actually saying that Windows is almost two decades behind the Mac on such a basic end-user feature? No wonder users are flocking to the Mac.... And judging by the comment about the ribbon bar, I'm guessing Windows will also require you to click a special button to do something that in any sane universe should just require a double-click....
As for the walled garden thing, that works well on new devices like tablets because there isn't an established market, so people don't have any preconceived expectations. I don't see that model completely displacing the established market in the computer space any time soon. There are just too many things that people use computers for that just don't fit that distribution model, from apps with plug-ins to command-line tools.
That doesn't mean it's a bad interface. It's a highly discoverable interface. The first time they click it, they see the menu pop up. Now they know that there are more options. The hard part is naming the button so that they understand what options are likely to be in it. Assuming you choose which options to group in this way correctly, even this aspect should not be all that hard. If it is, the mistake is not in using a button with a menu, but rather in your naming and/or grouping. (Okay, in extreme cases, this could mean that using it was a mistake if the right number of things to group together happened to be "none of them", but you know what I mean.)
In my experience, if you need labels on groups of buttons, it generally means that you didn't pick good enough labels or icons for the buttons within the group. Things that are conceptually similar should have names that sound conceptually similar, and their icons should be visually distinct such that even those dividers are unnecessary, much less named labels on groups of icons.
Further, if those labels are useful, that means that the user doesn't actually understand what those buttons do, and this typically indicates that the user in question should not have been exposed to those controls in the first place.
That's wrong at a fairly fundamental level. The goal of a user interface is not to show off every feature of an app. The goal of a user interface is to make it as easy as possible for users to discover the things they need in order to do their job. In other words, its main purpose is to get out of the way of the user. If a user interface is trying to highlight obscure features that the user probably will not need, the UI is an epic fail. Finding rarely used features is what help systems are for, not to mention the ability to search through menus by words in the name. (Or is that just a Mac OS X thing?)
If it's for regular users, then the ribbon for something like this should have roughly four buttons:
At most, add one more button for "preferences". That's it. Everything else there is unnecessary and confusing for regular people. What I'm seeing here is not designed for ordinary users. It is designed to try to show those ordinary users everything that power users might potentially want to do, which quite frankly is just about the worst offense you can possibly commit as a UI designer short of making all your controls hot pink on neon green....
Put another way, I think this blog post sums it all up nicely.
Not at all. I'm talking about a menu button for nearly identical choices (multiple variations of "copy", for example). It's a button that when you click it, a menu pops up. Choosing a selection from such a menu takes exactly the same number of clicks (1) as it does to choose that selection from individual buttons, yet reduces clutter in the user interface. Further, if that reduction in clutter prevented you from having to change tabs to get to the option, it takes two fewer clicks than having it as a separate button.
In fact, nearly every single suggestion I made provably does not add any clicks even in the worst case, and in most cases, requires fewer clicks to do the same thing.
It's a lot easier to click "choose columns" and click checkboxes by the ones you want in a sheet, then dismiss the sheet. Assuming that you typically stay on the main tab, then in the ribbon design, it takes one click to get to the View tab, a second click to choose the column to add or remove, plus a third click to get back to the main tab.
It similarly takes three clicks to do it with a sheet, but you get the nice, clean UI of getting to see all of the options all at once in a neatly laid out grid, which opens up the possibility for showing far more columns than are feasible in a linear list. It also means that it's a lot less clumsy to add or hide more than one column at a time.
The default behavior should be to auto-size the columns that are most likely to be relevant (the name being the obvious one), use ellipses in the middle of names when that isn't possible, and scale the rest. 99.99% of the time, that's what you want, and the rest of the time, auto-size isn't going to work any better than changing the window size. In effect, an auto-size button is a "fix the brokenness" button. Good UI design should not require such hacks.
Actually, statistically, a sizable percentage of users never open a second tab, so I wouldn't go so far as to say nobody minds. This is true across all browsers, BTW. (That particular study used a small sample size that didn't demonstrate this, but there are other studies on the subject.) Having multiple things in a single window is really not a good fit for most people's mental models.
Many folks use tabs because they find it handy to see the names of pages rather than cycling through the windows until they get to the right one. In the end, the experience doesn't really differ that much, though, except for users who do everything with a mouse. Power-users who are used to keyboard navigation usually don't really see the benefit to tabs over windows, and naive users don't understand how tabs work at all. So they basically only provide a tangible benefit for people in a fairly narrow band in the middle somewhere—people who are both experienced computer users and who have not yet discovered the joys of carpal tunnel syndrome from mousing too much....
Do I have usability studies on a prerelease mock-up of an interface? Of course not.
Is it obvious that putting "Zip" (compress) under a "Send" label is remarkably confusing? Of course.
Don't get me wrong, labels on individual buttons are very useful. Labels on segmented controls and similar are also useful. Labels on groups of loosely related buttons... not so much.
Probably this, but it's also possible that some other aspect of the experience is broken, so people do tasks frequently that they shouldn't have to do frequently. In general, if you're doing the same thing over and over, that's usually an indication that the application is failing to store some preference that it should be storing. I don't personally run Windows, so I can't say which.
The overarching problem here is that you shouldn't need nearly that many controls to do 90% of your work. If you have more than a dozen buttons, there's something very fundamentally wrong, and it's probably not just the buttons, but rather the entire way you're looking at the problem that you are trying to solve....
How is haphazardly mixing multiple sizes of buttons with complex scrolling controls and text an improvement in UI design? My gosh, have you actually looked at this thing?
Putting commonly used features within easy reach is inarguably good UI. Making it customizable so that the definition of "commonly used" can be modified by the user, however, is also inarguably good UI. Doing this, by definition, necessitates something approaching standardization of icon sizes, layouts, etc. Instead, what we have here looks like a Jackson Pollock painting.
Let's look at what's wrong with this UI design, point by point:
Tabbed navigation incorrectly used to select between banks of controls
Tabbed navigation is assumed to affect the contents of the screen as a whole. It is a fundamental abuse of the metaphor to use it to choose between banks of controls.
The need for tabs is a clear indication that you are bringing way too many controls to the forefront of the user's attention.
Most users won't notice the tabs, and will be confused if they accidentally click on one because they won't know how to get back to the controls that they're used to. They will, in turn, file bugs or call tech support.
Tabbed navigation shares a row with other information
I'm guessing that the blob called "File" is not part of the navigation tabs, but it appears to be. While it might seem convenient to reduce the vertical spacing by placing unrelated information in a tab bar, it's extremely confusing. It looks to me like two different things are selected in a single tab bar, which is just plain wrong.
Unhelpful grouping labels
Although conceptual grouping of icons can be useful in terns of keeping related things together, it is generally not useful to label those groups. This wastes valuable vertical screen real estate and adds nothing to the user's understanding. Yes, in some way, burning a file to disc is conceptually similar to emailing it to someone, but a label called "send" doesn't add meaning, and is actually a bit confusing.
Inconsistent levels of detail, and non-independent controls
There are wildly different levels of detail between different features in this UI. You have simple tasks like "Print" that presumably open their own dialog boxes, and then you have things like sharing preferences in which lots of detail is crammed into a single section of the ribbon bar for no good reason. "Sharing options" could be a single icon in a button bar that brings up a modal sheet or dialog box, and no convenience would be lost.
In general, UI elements should be independent unless you are in a dialog box or sheet. Clicking an item in a button bar or similar should cause either an action to occur or a dialog box to appear for getting more information. Items in button bars should absolutely not depend on other items in the bar for their behavior.
Minor variations have separate buttons instead of a pop-up menu
If there are several UI elements that conceptually do the same thing, then they should be combined into a single menu item with a pop-up menu to choose which specific variant action should be performed.
Example 1: "Send" button: display a pop-up for email, burning, etc. (Note: compressing a file is *not* an equivalent action, and should *not* be listed with the rest of those.)
Example 2: "Clipboard" button: for all of the various cut, copy, and paste options, show a hierarchical menu that pops up when you click the clipboard/pasteboard button.
By making those two changes, you've turned basically two ribbon bar tabs into two or three buttons with a couple of simple pop-up menus and a simple modal sheet.
Rarely used UI options are artificially elevated
Most people don't add or remove columns in their views regularly. That's the sort of thing that you pretty much do once when you first get a computer, assuming
Alternatively, we could confuse things even more and have "day zones" instead of "time zones". You know, define the day to be whatever day it was when the sun rose. :-)
No big deal. Just choose some time zone where nobody lives as the standard world time. That way, 2200 hours isn't sunset for very many people. Problem solved. GMT-9 and GMT-10 are pretty good candidates.
What's wrong with saying 4 deciliters?
I'm not saying it couldn't have made the transition. I've only seen a few tiny fragments of the Copland code base (that were ported to MkLinux), but what I saw looked like it would be reasonably portable.
My point was that by the time Apple acquired NeXT, it was already running on both PowerPC and Intel, which gave them a huge head start on the Intel transition just a few years later. I'm not sure when or if they ever stopped maintaining x86 support, but the last Darwin OS binary release in 2002 still contained Intel bits. I'd expect a big difference in effort between porting even a well-designed, highly portable OS from scratch and cleaning up an OS port that had been abandoned at most a couple of years earlier....
Definitely not. Copland was an interesting piece of software, and certainly much more modern than the 8 nanokernel (and it might even have been more modern than parts of Mac OS X, even—I'm not really sure), but the OS itself is not the whole story. In fact, it's arguably the least important part of the story.
Mac OS X wasn't just a replacement for Mac OS. It was also a usable UNIX. Copland certainly wouldn't have drawn the Linux/UNIX crowd the way NeXT did, and I think that had a real impact on the perception of Apple in the enterprise.
This, in turn, drove the intense popularity of Apple's laptops among the geek crowd (when other manufacturers' laptops weren't doing nearly as well). In an era when Apple was only three or four percent of the market, you could walk into a UNIX/Linux conference and half of the laptops would be Macs. Why? Because geeks wanted a usable laptop running some sort of UNIX variant, and running a laptop in Linux generally sucked at the time.
That popularity, in turn, caused all those geeks to recommend these things to their friends and families, which played a significant part in the rapid decline of desktop computing in favor of mobile computing in the first part of the last decade. The rapid shift towards laptops, in turn, was the reason Apple gave up on PowerPC and transitioned to Intel hardware—a transition that made Apple's computers immensely more popular almost overnight. How much of this was actually driven by Mac OS X being UNIX, I couldn't begin to guess, but I'm certain it was nonzero.
Also, NeXT brought with it functioning code for i386, and a functional set of developer tools (the GNU toolchain). The Intel transition would have been a lot harder with Copland, not to mention the whole ARM thing on iOS. Can you imagine if Apple were building iOS using CodeWarrior?
Finally, NeXT brought with it a lot of new blood. Apple doesn't usually acquire companies for technology. It acquires companies because it wants their employees. From what I hear from people who worked at Apple in that era, the NeXT merger created all sorts of culture clash initially, but in the end, it resulted in a much stronger company than either company could have become on its own.
And, of course, the merger brought back Steve Jobs. You can argue all you want about whether Steve actually made decisions that no one else could have or would have made, but ultimately that's not what matters. What matters is that one of the guys who founded the company was back at the helm. Psychologically speaking, I think that did more to get Apple back on its feet than anything else, including the NeXT merger, including any single decision that Steve made, including even the advent of the iPhone.
If it requires several thousand dollars in custom hardware, it's not likely to be happening in very many places. By contrast, any jackass with a standard issue laptop can snoop open Wi-Fi.
So yeah, GSM might be sniffable, but it's still statistically a few orders of magnitude less likely to be sniffed than unencrypted Wi-Fi.
Not going to mod parent up as Funny because I might want to post in this thread at some point, but I LOLed.
Early horseless carriages were quite literally horseless carriages in every way. They looked like a carriage, they drove on the same roads as a carriage, etc. About the only differences were the lack of hardware to attach to a horse, which is kind of expected given that they were horseless, and different controls for driving the things.
I would therefore similarly expect a flying car to be a flying car, with the same functionality as a car, but with different controls and the ability to fly.
I think if such tampering had occurred, there would be loads of evidence of it, particularly given that ancient copies of those texts still exist and are regularly studied.
Although you may not agree with the remedy, much like chiropractic care for back pain, it can be an effective treatment for some types of problems. Many religious laws solved some fundamental problem (which may or may not still be a problem today).
For example, many of the dietary laws in Jewish and Muslim religion are believed to have been written to prevent certain types of food-borne illness. Mixing meat with dairy, if not done correctly, often results in undercooked meat. Eating pork results in greater contamination of the water supply because pigs require so much water that they tend to be farmed close to river. And so on.
For another example, many of the religious laws on sex stem from a fundamentally sound, albeit primitive, understanding of genetics. Having sex with close family members tends to result in all sorts of recessive traits becoming much more common, including a number of harmful mutations.
Heck, even prohibitions against wearing two kinds of clothing are useful for preventing static electricity buildup, which in a primitive society, could be misinterpreted as punishment from God, and could cause all sorts of really stupid mistakes.
I think the more interesting question is this: many of these religious laws suggest an understanding of medicine that is way beyond the understanding of the people who wrote them. Was this dumb luck, or is it the hand of God working among us? (Or, alternatively, did we get visited by aliens, if you'd prefer?)
I couldn't disagree more.
First, people want simplified user interfaces on tablet-based devices because the hardware design (touching the actual screen) cannot handle more complex user interfaces. I'm not convinced that dumbing down the desktop to look like mobile devices is a win for anyone. Different devices are best served by different interfaces.
Second, for the people who want simplified UIs, there are already plenty of cheap or free apps out there that provide basic drawing (or, more commonly, basic photo cropping, scaling, and color correction, which turns out to be what 99% of novice graphics work entails). For GIMP to be useful, it needs to focus more on the underserved high end, not the thoroughly served low end.
A streamlined interface for newbies certainly isn't a bad idea for tripling the newbie traffic on the help mailing lists, if that's your goal, but it benefits few current GIMP users, whereas fixing the flaws in the existing UI would help current users and would make it more attractive to (moderately advanced) new users as well.
A flying car must, by definition, be A. flying, and B. a car. Try to drive one of those airplanes on the highway, and you'll quickly discover why airplanes are not flying cars. Flying machines, sure, but not flying cars.
A helicopter is a lot closer to a flying car than any airplane, or at least it behaves a lot more like a car in that it can sit still without falling from the sky, requires a relatively small landing area, etc.
For what? Viewing 320x240 thumbnails of the actual video data? You do know that the maximum data throughput of even EDR Bluetooth is only 2.1 megabits per second, right? And that typical AVCHD camcorders run at about 12 megabits per second? And that DV or HDV video is 25 megabits per second (or 50 megabits per second in some variants)?
Even Wi-Fi would work only if the two devices are close together and if no other devices are clogging the spectrum. Wireless data transfer has come a long way, but it is still nowhere near the point where it makes sense to use it as a primary means of connecting video gear. We need speeds that are at least an order of magnitude faster.
Agreed. It's slow, buggy, and it crashes browsers and/or browser helpers with such regularity that one can safely assume that the mere existence of Flash on your computer or device poses a security hole so big you could drive a truck through it.
Flash also leads people to create overly complex web site designs that don't work well over slow connections (e.g. EDGE, 3G, etc.) and waste tons of bandwidth that could cost customers actual money on metered networks (Comcast, AT&T DSL/U-Verse, pretty much all cellular services, and many others). Add to that all the stupid banner ads and other such nonsense that uses Flash for no good reason, and it is really a bandwidth pig.
Finally, Flash is inherently fundamentally incompatible with small devices like phones because of its CPU overhead. If I play a Flash game on my laptop, I can run the battery down in about an hour and a half. Doing normal work, my laptop lasts six hours. Scale that to a phone, and you can safely assume that if every web page used Flash, your smartphones would have to be recharged several times a day just from doing light web browsing.
So yeah, it's a feature. As much as I'd like the option of installing Flash on my iPhone (in a *separate* web browser that only gets used for the occasional site that require it), I'm really glad it doesn't come with it installed by default, and given the choice between no Flash at all and built-in Flash, I'd pick no Flash in a heartbeat.
Agreed. Calling it 16-bit color is just plain abusing the terminology. The correct term is "16-bit channels", not "16-bit color". Alternatively, one can call it "48-bit color".