I would differentiate between easy to use and easy to learn. The latter is arguably more important, because if the learning curve is shallow, then the perecption of something being eay to use is more likely.
I don't particularly like to use the word intuitive since it gets people into this idea that we double-click a mouse in the same way a duck paddles its feet in water. That's not really what intuitive means -- it means easy to deduce, not innate, but some people think we're talking about blinking or our gag reflex when we use the word. Anyway, I probably misspoke when I said "intuitive" before. I used it to mean easy to use, when now that I think about it, it has more to do with learning than with using since you've already done the intuition if you're using with any proficiency. Bah, it gets all cognitive and stuff! In any case, I think "sophistication" is a better word for describing the goal of UI design, more than "intuitive."
Consistency and Elegance as applied to an OS or windowing environment is really hard to define. It underlies more than any single definition can provide (I think) and is a system wide experience. I, and any of us, can give examples of good consistent behavior and bad inconsistent behavior without quite knowing why. It's one of those things that when we see it, we know we like it, and when we see otherwise, we know something is wrong.
As was pointed out, being technically consistent isn't enough. Dragging and dropping of files could always give the file path in any situation (technically consistent) but in most cases, that's not what we want (intuitively consistent).
It's has got to be an incredibly difficult job to do, especially to please the most people as possible without making it overwhelming for the rest. Though they don't have everything right, I have to applaud Apple's UI design team for what they have made. Innovations like Éxposé would never have occurred to me, and though it might not be prefect yet, it's really awesome at what it does!
Consistency and Elegance as applied to an OS or windowing environment is really hard to define. It underlies more than any single definition can provide (I think) and is a system wide experience. I, and any of us, can give examples of good consistent behavior and bad inconsistent behavior without quite knowing why. It's one of those things that when we see it, we know we like it, and when we see otherwise, we know something is wrong.
As was pointed out, being technically consistent isn't enough. Dragging and dropping of files could always give the file path in any situation (technically consistent) but in most cases, that's not what we want (intuitively consistent).
Consistent = logically consistent. Consistent software closely follows internal rules which form a model. Whether we perceive it consistent or not depends on if our model and the software's model are close to each other.
Making software easy to use means to make it consistent (which allows the users to understand the system), and to use models that are a close fit to models the intended user is familiar with (to make the system easier to learn, and more intuitive).
But frankly...tabs are really stupid for a chat app. How many simultaneous conversations can one have at a time? If the answer is 'less than 5' then let the sessions be in separate windows and let Exposé do the rest.
You don't have many friends?
OK yeah I know I'm a loser I talk to way to many people online. Like 20 at a time. Tabs are AWESOME. Finally. Now if they could just make it WORK with AIM. Sending, formatting, etc. just never work 100%. iChat just doesn't work. AIM for Mac is missing a huge array of AIM features, but the ones it supports work. Except for a few bugs like text turning black after pasting a link, a bug I reported to them over a year ago and they haven't done anything about it. Same about getting Info taking forever, unless you move the mouse, for some odd reason. Of course, how long as Apple known that animated GIFs slow Safari down so even text can't be typed? I digress. AOL AIM has Mac clients that support every AIM 5.5 (soon 6?) feature perfectly. And until AOL makes a decent AIM for Mac or lets Apple "under the tent" all the damn way, there won't be one. Proteus and the official Mac AIM are the best I've seen so far. Adium is decent. iChat is a nice idea but just doesn't work.
Jumping back a bit, OS X certainly has some issues with its hide and minimise behaviour.
Apparently one of the rules for hiding is that you cannot hide all of the running applications.
But, for consistency, you can hide the finder.
When you hide the finder another app jumps up to take its place, and then another, and another, as you try to hide them.
This is a an edge condition in hiding ( what happens when you hide the last app ), and the selected behaviour breaks the consistency of hiding ( it unhides an app ). I think that the justification is probably that people can have a shortcut in their workflow ( jump from one app to another ).
I HATE IT.
I HATE IT.
grr, it makes me soooo mad.
I really shouldnt get so emotional about it.
I am trying to break my habit, expose is great for getting at the desktop. I use it a lot now-a-days.
Expose will help me feel better, just one more dose.......
*I* know that the Desktop is a Finder window, and *you* know that... average user hasn't a clue, so the Finder repeatedly popping up in their face is going to annoy them. "But I *hid* the Finder... what the heck?"
The current approach is the best compromise I've seen, since as mmmpie pointed out, the effect *can* be used as part of a workflow. I prefer Cmd-tab to pop quickly between two apps, but I can see someone using this instead.
My geeky heart still thinks that hiding all apps should just leave the Dock, but that's only because I know enough about the underlying system to not be surprised.
*I* know that the Desktop is a Finder window, and *you* know that... average user hasn't a clue, so the Finder repeatedly popping up in their face is going to annoy them. "But I *hid* the Finder... what the heck?"
The current approach is the best compromise I've seen, since as mmmpie pointed out, the effect *can* be used as part of a workflow. I prefer Cmd-tab to pop quickly between two apps, but I can see someone using this instead.
My geeky heart still thinks that hiding all apps should just leave the Dock, but that's only because I know enough about the underlying system to not be surprised.
I actually thought that all the "regular" Finder windows would get hidden, but on second thought that is quite illogical and useless behavior. You are right in that only Dock should remain. What I want to know, should desktop contents be hidden too?
It's totally silly (though logical) that clicking the Desktop makes hidden Finder windows pop up. This is a concrete example of why OS X hide is bad from the ground up.
Actually, I think it's more of a symptom of the Finder controlling the Desktop being a bad design. It's an 'invisible window'? WTH? Make Desktop functionality tied with the Dock as the 'bottom layer' of the UI, not tied in with the Finder. Yeah, it's a Finder window behind the scenes, but to the user, it's anything but.
That way, you could hide Finder, and all other apps, and still have Dock and Desktop available as your basic entry point.
OTOH, this is a good argument for having Finder pop up as the last unhideable app... kind of like OS 9... er... *gulp*
Totally wrong. Who's forcing you to use an interface someone else customized for himself? If you want the standard interface, you use the standard interface.
If I lost both my hands in an accident, I would definitely want a feet-steered car.
Intuitiveness and consistency in interfaces are subjective. Both depend on how close the user's thought model and the software's logic correspond.
Actually, consistency is objective. That's the whole point of consistency. Intuitiveness is subjective to a point, or the great bulk of Apple's UI work is pointless and fruitless by definition. For instance, it's intuitive to most people that folders organize things.
Basically, your argument is that there is no model or model(s) that most closely correspond(s) to a given set of functionality. I disagree. And I point to those UIs that agree with your stance - Motif, Gnome - all of which are difficult to learn, difficult to use, non-discoverable, inconsistent, unintuitive, and ugly. Furthermore, and no less crucially for real-world use, the more variables you allow, the more bugs and flaws and inconsistencies you allow in both the system and the applications written for it. Choice is fine when research reveals that there really is more than one way to get something done. But at some point, whether because it prevents a metaphor from collapsing (intuitiveness, discoverability) or because it simply came out favorably in testing, there is generally a best way to get something done.
This is the whole point of the old Inside Macintosh HIG book (and, actually, much of the point of all the other IM books), which I'd highly recommend reading if you're serious about this.
Actually, consistency is objective. That's the whole point of consistency. Intuitiveness is subjective to a point, or the great bulk of Apple's UI work is pointless and fruitless by definition. For instance, it's intuitive to most people that folders organize things.
The common definition of consistency is how well the software adheres to a single, abstract logical model (internal consistency). This is objective. But, most software does not have a simple, 100% consistent logic. This means that when you try to form a model of it in your head, there are more than one model that all fit the software pretty well. Also, beginners often work with a model that is very removed from the best model(s) - they can't and won't grasp the full model right away. These factors and internal consistency combined are external consistency, which is subjective. Alternatively, sticking with the narrow definition leaves a big empty area between consistency and intuitiveness. If you know of a better name for that, suggest one.
Quote:
Basically, your argument is that there is no model or model(s) that most closely correspond(s) to a given set of functionality. I disagree. And I point to those UIs that agree with your stance - Motif, Gnome - all of which are difficult to learn, difficult to use, non-discoverable, inconsistent, unintuitive, and ugly. Furthermore, and no less crucially for real-world use, the more variables you allow, the more bugs and flaws and inconsistencies you allow in both the system and the applications written for it. Choice is fine when research reveals that there really is more than one way to get something done. But at some point, whether because it prevents a metaphor from collapsing (intuitiveness, discoverability) or because it simply came out favorably in testing, there is generally a best way to get something done.
I never said there isn't generally a single good way to accomplish a given task. It's good to provide one such a way to the user. Likewise, it's good to give options, neatly tucked away, for those who want/need them. (Disclaimer: I am not a Gnome expert.) Gnome's public policy is that it is dedicated to giving the user one good way of doing things. They go through the trouble to push advanced options out of sight. Their latest releases have concentrated on HIG and usability over features. KDE folks fit your criticism better.
You didn't address the missing hands scenario. It's not just disabilities either: a person who's using some software eight hours a day might want to go through a lot of initial trouble in order to save fifteen minutes a day eventually. Why not allow him to do that? Why not give the handless man a chance to drive a car?
Except that what you're advocating is making sure that every auto sold has the option available for handless drivers, including it with every car at added expense that is unnecessary for 99.99% of the consumers.
It is much better to allow for after-market modifications for such users who need such things, and that is precisely what the auto market does now.
If you really want to pursue this comparison, then it would make sense for Apple to provide the best possible singular way (or very few ways) for a UI, and allow third party developers to fill in the special workflow needs of the smaller niche markets. Just like the auto companies do. Just like Apple does now.
And before you say that Apple doesn't provide the hooks to allow this sort of thing, take a look at the Accessibility API. There is a MASSIVE amount of customization possibility in there, hidden under the 'Accessibility' moniker.
First, I did not talk about Apple and what they have and have not done, my comments were about design in general.
I don't want to pursue the auto comparison because it is poor, automobiles have lots of physical constraints and are not comparable to software. I wasn't the one to bring the whole comparison into the discussion, Amorph was. I merely pointed out that even in his extreme "useless customization" scenario there would have been people who would have wanted to customize their vehicle. Whenever the developer makes a design decision, it is represented in code. If the code is good, most decisions are abstracted and cleanly separated from each other. ]Then it is generally very little bother to put in a configuration/option system, that lets people change that decision without having access to the source and having to compile it. Mostly, this is worth doing even just for development team internal use. A programming API is the next step in extensibility. Open sourcing the program is also a possibility. I'm just arguing that the company should expose as much of the *existing* internals of the program as possible, and seriously consider including additional extensibility features. In no circumstances should the internals be hidden from those who are interested in tweaking them. The developer should not assume to know all the uses the users would like to put the software to.
Oh holy crap. Bad mod. Gon, I hit edit instead of reply, and edited your post by mistake. Your content is all here, but my quote is gone. Oops.
First, I did not talk about Apple and what they have and have not done, my comments were about design in general.
I don't want to pursue the auto comparison because it is poor, automobiles have lots of physical constraints and are not comparable to software. I wasn't the one to bring the whole comparison into the discussion, Amorph was. I merely pointed out that even in his extreme "useless customization" scenario there would have been people who would have wanted to customize their vehicle.
Indeed. But it is not the purpose of the designers to fulfill every possible user's desire simultaneously, only to provide a best fit for the majority of the userbase. As you point out below, designers can *not* anticipate every possible need. Therefore they must provide the best solution for most, and optimally an API for developers to provide after-market solutions for niche markets.
Quote:
Whenever the developer makes a design decision, it is represented in code. If the code is good, most decisions are abstracted and cleanly separated from each other.
Agreed.
Quote:
Then it is generally very little bother to put in a configuration/option system, that lets people change that decision without having access to the source and having to compile it.
Er, no. Each design decision must then be coded, tested, and supported N times for each option... which leads to an explosion of possible combinations, all of which must be tested as well. It's not linear, it's geometric. Reducing any one option pool reduces the testing and support load significantly.
Studies have shown that on average, 85% of the total cost of software development is in *maintenance*, if you can believe it. Anything you can do to alleviate that is a big win.
You can create orthogonal and correctly abstract areas of design, but choices oh how to implement those areas are still going to be discrete chunks of code that must be written, tested, and supported independently. And then in concert with other areas. Ad nauseum.
Quote:
Mostly, this is worth doing even just for development team internal use.
Which is a TOTALLY different environment than the end user. See, this is where the Gnome/KDE/Motif folks just don't get it: massive customizability, options, and such are great *for developers*... but not for the vast majority of end users. Many choices among a plethora of poorly designed solutions is no solution at all for the consumer.
Quote:
A programming API is the next step in extensibility. Open sourcing the program is also a possibility. I'm just arguing that the company should expose as much of the *existing* internals of the program as possible, and seriously consider including additional extensibility features.
Exposing internals is a direct violation of abstraction.
Quote:
In no circumstances should the internals be hidden from those who are interested in tweaking them. The developer should not assume to know all the uses the users would like to put the software to.
Nor should the user assume to know all the variables behind a decision by the development team.
Extension APIs are a good thing. A language that supported dynamic extension, such as Obj-C is better.
Seriously, if there were a market for such customizations, it is *not* technically impossible. Difficult, maybe, but come on... that's what l33t developers are for...
Which is a TOTALLY different environment than the end user. See, this is where the Gnome/KDE/Motif folks just don't get it: massive customizability, options, and such are great *for developers*... but not for the vast majority of end users. Many choices among a plethora of poorly designed solutions is no solution at all for the consumer.
Regarding their overall quality, I believe they are works in progress and should be judged as such. It says something that I moved on OS X, not the free desktops, when I decided to dump Windows. Customizability and options as such cannot be a negative thing, if those users who do not need them, never see them. If there is a 5% of "developers" among the userbase that can use those options for something, great.
On Gnome, you don't *have* to boot up GConf, its existence just means the obscure stuff is available in a reasonably consistent form should you want to tweak it. Also on OS X, there are tons of options and miscellaneous data around the system in configuration files and Netinfo - it doesn't mean you *have* to ever go beyond the individual apps' Preferences and the System Preferences.
Regarding their overall quality, I believe they are works in progress and should be judged as such. It says something that I moved on OS X, not the free desktops, when I decided to dump Windows. Customizability and options as such cannot be a negative thing, if those users who do not need them, never see them. If there is a 5% of "developers" among the userbase that can use those options for something, great.
On Gnome, you don't *have* to boot up GConf, its existence just means the obscure stuff is available in a reasonably consistent form should you want to tweak it. Also on OS X, there are tons of options and miscellaneous data around the system in configuration files and Netinfo - it doesn't mean you *have* to ever go beyond the individual apps' Preferences and the System Preferences.
Customizability and options are not a negative thing. Too many customizability options are.
If the extra options are buried out of normal sight, then it's fine. The only options that should be visible are the options the majority of users would use often.
Comments
Originally posted by kim kap sol
Intuitiveness and ease-of-use normally go hand-in-hand. I have trouble finding an example where they don't.
Things are easy when they are intuitive.
Or when you learn the system, which you must do for everything
Example: screen
Hard to use at first, but once you learn it, very easy, and very intuitive
I don't particularly like to use the word intuitive since it gets people into this idea that we double-click a mouse in the same way a duck paddles its feet in water. That's not really what intuitive means -- it means easy to deduce, not innate, but some people think we're talking about blinking or our gag reflex when we use the word. Anyway, I probably misspoke when I said "intuitive" before. I used it to mean easy to use, when now that I think about it, it has more to do with learning than with using since you've already done the intuition if you're using with any proficiency. Bah, it gets all cognitive and stuff!
As was pointed out, being technically consistent isn't enough. Dragging and dropping of files could always give the file path in any situation (technically consistent) but in most cases, that's not what we want (intuitively consistent).
It's has got to be an incredibly difficult job to do, especially to please the most people as possible without making it overwhelming for the rest. Though they don't have everything right, I have to applaud Apple's UI design team for what they have made. Innovations like Éxposé would never have occurred to me, and though it might not be prefect yet, it's really awesome at what it does!
Code Master
Originally posted by Code Master
Consistency and Elegance as applied to an OS or windowing environment is really hard to define. It underlies more than any single definition can provide (I think) and is a system wide experience. I, and any of us, can give examples of good consistent behavior and bad inconsistent behavior without quite knowing why. It's one of those things that when we see it, we know we like it, and when we see otherwise, we know something is wrong.
As was pointed out, being technically consistent isn't enough. Dragging and dropping of files could always give the file path in any situation (technically consistent) but in most cases, that's not what we want (intuitively consistent).
Consistent = logically consistent. Consistent software closely follows internal rules which form a model. Whether we perceive it consistent or not depends on if our model and the software's model are close to each other.
Making software easy to use means to make it consistent (which allows the users to understand the system), and to use models that are a close fit to models the intended user is familiar with (to make the system easier to learn, and more intuitive).
But frankly...tabs are really stupid for a chat app. How many simultaneous conversations can one have at a time? If the answer is 'less than 5' then let the sessions be in separate windows and let Exposé do the rest.
You don't have many friends?
OK yeah I know I'm a loser I talk to way to many people online. Like 20 at a time. Tabs are AWESOME. Finally. Now if they could just make it WORK with AIM. Sending, formatting, etc. just never work 100%. iChat just doesn't work. AIM for Mac is missing a huge array of AIM features, but the ones it supports work. Except for a few bugs like text turning black after pasting a link, a bug I reported to them over a year ago and they haven't done anything about it. Same about getting Info taking forever, unless you move the mouse, for some odd reason. Of course, how long as Apple known that animated GIFs slow Safari down so even text can't be typed? I digress. AOL AIM has Mac clients that support every AIM 5.5 (soon 6?) feature perfectly. And until AOL makes a decent AIM for Mac or lets Apple "under the tent" all the damn way, there won't be one. Proteus and the official Mac AIM are the best I've seen so far. Adium is decent. iChat is a nice idea but just doesn't work.
Apparently one of the rules for hiding is that you cannot hide all of the running applications.
But, for consistency, you can hide the finder.
When you hide the finder another app jumps up to take its place, and then another, and another, as you try to hide them.
This is a an edge condition in hiding ( what happens when you hide the last app ), and the selected behaviour breaks the consistency of hiding ( it unhides an app ). I think that the justification is probably that people can have a shortcut in their workflow ( jump from one app to another ).
I HATE IT.
I HATE IT.
grr, it makes me soooo mad.
I really shouldnt get so emotional about it.
I am trying to break my habit, expose is great for getting at the desktop. I use it a lot now-a-days.
Expose will help me feel better, just one more dose.......
"OMG! My menu bar just disappeared/went blank! Where the hell did everything go?!?"
I don't think it's for workflow, but for lack-of-surprise factor.
Originally posted by Kickaha
Actually, if you hide all the apps... what happens to the menu bar?
"OMG! My menu bar just disappeared/went blank! Where the hell did everything go?!?"
I don't think it's for workflow, but for lack-of-surprise factor.
If you hide "everything", what stays visible is the desktop, which is a Finder window. You should get the Finder menubar IMO.
The current approach is the best compromise I've seen, since as mmmpie pointed out, the effect *can* be used as part of a workflow. I prefer Cmd-tab to pop quickly between two apps, but I can see someone using this instead.
My geeky heart still thinks that hiding all apps should just leave the Dock, but that's only because I know enough about the underlying system to not be surprised.
Originally posted by Kickaha
*I* know that the Desktop is a Finder window, and *you* know that... average user hasn't a clue, so the Finder repeatedly popping up in their face is going to annoy them. "But I *hid* the Finder... what the heck?"
The current approach is the best compromise I've seen, since as mmmpie pointed out, the effect *can* be used as part of a workflow. I prefer Cmd-tab to pop quickly between two apps, but I can see someone using this instead.
My geeky heart still thinks that hiding all apps should just leave the Dock, but that's only because I know enough about the underlying system to not be surprised.
I actually thought that all the "regular" Finder windows would get hidden, but on second thought that is quite illogical and useless behavior. You are right in that only Dock should remain. What I want to know, should desktop contents be hidden too?
It's totally silly (though logical) that clicking the Desktop makes hidden Finder windows pop up. This is a concrete example of why OS X hide is bad from the ground up.
That way, you could hide Finder, and all other apps, and still have Dock and Desktop available as your basic entry point.
OTOH, this is a good argument for having Finder pop up as the last unhideable app... kind of like OS 9... er... *gulp*
Originally posted by Gon
Totally wrong. Who's forcing you to use an interface someone else customized for himself? If you want the standard interface, you use the standard interface.
If I lost both my hands in an accident, I would definitely want a feet-steered car.
Intuitiveness and consistency in interfaces are subjective. Both depend on how close the user's thought model and the software's logic correspond.
Actually, consistency is objective. That's the whole point of consistency. Intuitiveness is subjective to a point, or the great bulk of Apple's UI work is pointless and fruitless by definition. For instance, it's intuitive to most people that folders organize things.
Basically, your argument is that there is no model or model(s) that most closely correspond(s) to a given set of functionality. I disagree. And I point to those UIs that agree with your stance - Motif, Gnome - all of which are difficult to learn, difficult to use, non-discoverable, inconsistent, unintuitive, and ugly. Furthermore, and no less crucially for real-world use, the more variables you allow, the more bugs and flaws and inconsistencies you allow in both the system and the applications written for it. Choice is fine when research reveals that there really is more than one way to get something done. But at some point, whether because it prevents a metaphor from collapsing (intuitiveness, discoverability) or because it simply came out favorably in testing, there is generally a best way to get something done.
This is the whole point of the old Inside Macintosh HIG book (and, actually, much of the point of all the other IM books), which I'd highly recommend reading if you're serious about this.
Originally posted by Amorph
Actually, consistency is objective. That's the whole point of consistency. Intuitiveness is subjective to a point, or the great bulk of Apple's UI work is pointless and fruitless by definition. For instance, it's intuitive to most people that folders organize things.
The common definition of consistency is how well the software adheres to a single, abstract logical model (internal consistency). This is objective. But, most software does not have a simple, 100% consistent logic. This means that when you try to form a model of it in your head, there are more than one model that all fit the software pretty well. Also, beginners often work with a model that is very removed from the best model(s) - they can't and won't grasp the full model right away. These factors and internal consistency combined are external consistency, which is subjective. Alternatively, sticking with the narrow definition leaves a big empty area between consistency and intuitiveness. If you know of a better name for that, suggest one.
Basically, your argument is that there is no model or model(s) that most closely correspond(s) to a given set of functionality. I disagree. And I point to those UIs that agree with your stance - Motif, Gnome - all of which are difficult to learn, difficult to use, non-discoverable, inconsistent, unintuitive, and ugly. Furthermore, and no less crucially for real-world use, the more variables you allow, the more bugs and flaws and inconsistencies you allow in both the system and the applications written for it. Choice is fine when research reveals that there really is more than one way to get something done. But at some point, whether because it prevents a metaphor from collapsing (intuitiveness, discoverability) or because it simply came out favorably in testing, there is generally a best way to get something done.
I never said there isn't generally a single good way to accomplish a given task. It's good to provide one such a way to the user. Likewise, it's good to give options, neatly tucked away, for those who want/need them. (Disclaimer: I am not a Gnome expert.) Gnome's public policy is that it is dedicated to giving the user one good way of doing things. They go through the trouble to push advanced options out of sight. Their latest releases have concentrated on HIG and usability over features. KDE folks fit your criticism better.
You didn't address the missing hands scenario. It's not just disabilities either: a person who's using some software eight hours a day might want to go through a lot of initial trouble in order to save fifteen minutes a day eventually. Why not allow him to do that? Why not give the handless man a chance to drive a car?
It is much better to allow for after-market modifications for such users who need such things, and that is precisely what the auto market does now.
If you really want to pursue this comparison, then it would make sense for Apple to provide the best possible singular way (or very few ways) for a UI, and allow third party developers to fill in the special workflow needs of the smaller niche markets. Just like the auto companies do. Just like Apple does now.
And before you say that Apple doesn't provide the hooks to allow this sort of thing, take a look at the Accessibility API. There is a MASSIVE amount of customization possibility in there, hidden under the 'Accessibility' moniker.
I don't want to pursue the auto comparison because it is poor, automobiles have lots of physical constraints and are not comparable to software. I wasn't the one to bring the whole comparison into the discussion, Amorph was. I merely pointed out that even in his extreme "useless customization" scenario there would have been people who would have wanted to customize their vehicle. Whenever the developer makes a design decision, it is represented in code. If the code is good, most decisions are abstracted and cleanly separated from each other. ]Then it is generally very little bother to put in a configuration/option system, that lets people change that decision without having access to the source and having to compile it. Mostly, this is worth doing even just for development team internal use. A programming API is the next step in extensibility. Open sourcing the program is also a possibility. I'm just arguing that the company should expose as much of the *existing* internals of the program as possible, and seriously consider including additional extensibility features. In no circumstances should the internals be hidden from those who are interested in tweaking them. The developer should not assume to know all the uses the users would like to put the software to.
Oh holy crap. Bad mod. Gon, I hit edit instead of reply, and edited your post by mistake. Your content is all here, but my quote is gone. Oops.
First, I did not talk about Apple and what they have and have not done, my comments were about design in general.
I don't want to pursue the auto comparison because it is poor, automobiles have lots of physical constraints and are not comparable to software. I wasn't the one to bring the whole comparison into the discussion, Amorph was. I merely pointed out that even in his extreme "useless customization" scenario there would have been people who would have wanted to customize their vehicle.
Indeed. But it is not the purpose of the designers to fulfill every possible user's desire simultaneously, only to provide a best fit for the majority of the userbase. As you point out below, designers can *not* anticipate every possible need. Therefore they must provide the best solution for most, and optimally an API for developers to provide after-market solutions for niche markets.
Whenever the developer makes a design decision, it is represented in code. If the code is good, most decisions are abstracted and cleanly separated from each other.
Agreed.
Then it is generally very little bother to put in a configuration/option system, that lets people change that decision without having access to the source and having to compile it.
Er, no. Each design decision must then be coded, tested, and supported N times for each option... which leads to an explosion of possible combinations, all of which must be tested as well. It's not linear, it's geometric. Reducing any one option pool reduces the testing and support load significantly.
Studies have shown that on average, 85% of the total cost of software development is in *maintenance*, if you can believe it. Anything you can do to alleviate that is a big win.
You can create orthogonal and correctly abstract areas of design, but choices oh how to implement those areas are still going to be discrete chunks of code that must be written, tested, and supported independently. And then in concert with other areas. Ad nauseum.
Mostly, this is worth doing even just for development team internal use.
Which is a TOTALLY different environment than the end user. See, this is where the Gnome/KDE/Motif folks just don't get it: massive customizability, options, and such are great *for developers*... but not for the vast majority of end users. Many choices among a plethora of poorly designed solutions is no solution at all for the consumer.
A programming API is the next step in extensibility. Open sourcing the program is also a possibility. I'm just arguing that the company should expose as much of the *existing* internals of the program as possible, and seriously consider including additional extensibility features.
Exposing internals is a direct violation of abstraction.
In no circumstances should the internals be hidden from those who are interested in tweaking them. The developer should not assume to know all the uses the users would like to put the software to.
Nor should the user assume to know all the variables behind a decision by the development team.
Extension APIs are a good thing. A language that supported dynamic extension, such as Obj-C is better.
Seriously, if there were a market for such customizations, it is *not* technically impossible. Difficult, maybe, but come on... that's what l33t developers are for...
Originally posted by Kickaha
Which is a TOTALLY different environment than the end user. See, this is where the Gnome/KDE/Motif folks just don't get it: massive customizability, options, and such are great *for developers*... but not for the vast majority of end users. Many choices among a plethora of poorly designed solutions is no solution at all for the consumer.
Regarding their overall quality, I believe they are works in progress and should be judged as such. It says something that I moved on OS X, not the free desktops, when I decided to dump Windows. Customizability and options as such cannot be a negative thing, if those users who do not need them, never see them. If there is a 5% of "developers" among the userbase that can use those options for something, great.
On Gnome, you don't *have* to boot up GConf, its existence just means the obscure stuff is available in a reasonably consistent form should you want to tweak it. Also on OS X, there are tons of options and miscellaneous data around the system in configuration files and Netinfo - it doesn't mean you *have* to ever go beyond the individual apps' Preferences and the System Preferences.
Originally posted by Gon
Regarding their overall quality, I believe they are works in progress and should be judged as such. It says something that I moved on OS X, not the free desktops, when I decided to dump Windows. Customizability and options as such cannot be a negative thing, if those users who do not need them, never see them. If there is a 5% of "developers" among the userbase that can use those options for something, great.
On Gnome, you don't *have* to boot up GConf, its existence just means the obscure stuff is available in a reasonably consistent form should you want to tweak it. Also on OS X, there are tons of options and miscellaneous data around the system in configuration files and Netinfo - it doesn't mean you *have* to ever go beyond the individual apps' Preferences and the System Preferences.
Customizability and options are not a negative thing. Too many customizability options are.
If the extra options are buried out of normal sight, then it's fine. The only options that should be visible are the options the majority of users would use often.