SQLServerCentral / Editorials / SQLServerCentral.com / The Flaws of Choice / Latest Posts

RE: The Flaws of Choice

Gary Varga — Wed, 09 Dec 2009 12:04:11 GMT

[quote][b]jay holovacs (12/7/2009)[/b][hr]too many options is often a prodduct of bad design.Either the designer does not understand how the user is using the product, or is basically lazy to find out. There is nothing wrong with flexibility, but there should be a basic default and if there is a need to deviate from that, the process should be straightforward.I have that problem with Subway. The food is decent, but you can't simply order a sandwich. You need to go through a checklist, bread, meat, cheese, condiments.... etc. Nice to have choice but a pain to have to spell it out every time.[/quote]Subway must not travel well...the food is decent???

RE: The Flaws of Choice

GSquared — Tue, 08 Dec 2009 09:31:20 GMT

[quote][b]Steve Jones - Editor (12/8/2009)[/b][hr][quote][b]GSquared (12/8/2009)[/b][hr][quote]... (darn, I just went blank on what the management tool was for SQL 2000)...[/quote]Enterprise Manager, and I liked that. I think SSMS is OK, but I'd also like a QA type tool. I lived in that for SQL 2000, rarely using EM unless I needed the tool for a specific purpose[/quote]Maybe it's been too long since I used QA. (It's obviously been long enough since I used EM that I couldn't even remember it's name.)What feature(s) of SSMS would you prefer weren't there, that would make it match QA more?I see both of them as sort of a text editor that can execute a query when I hit F5.

RE: The Flaws of Choice

jcrawf02 — Tue, 08 Dec 2009 09:10:19 GMT

I think I'm on Steve's side of the fence here, because when I order at places and they ask me if I want each individual ingredient I want to just point at the menu and say "I want what you're showing is on the damn thing!"However, it's definitely a give and take thing, because it's nice to have the option to change things, and not being able to get it with or without an additional ingredient is annoying. But it's about the interface to get there. Make the defaults simple, but make them configurable, so everyone's "default" can be customized.

RE: The Flaws of Choice

Steve Jones - SSC Editor — Tue, 08 Dec 2009 07:27:21 GMT

[quote][b]GSquared (12/8/2009)[/b][hr][quote]... (darn, I just went blank on what the management tool was for SQL 2000)...[/quote]Enterprise Manager, and I liked that. I think SSMS is OK, but I'd also like a QA type tool. I lived in that for SQL 2000, rarely using EM unless I needed the tool for a specific purpose

RE: The Flaws of Choice

GSquared — Tue, 08 Dec 2009 07:18:02 GMT

[quote][b]majorbloodnock (12/8/2009)[/b][hr][quote][b]GSquared (12/8/2009)[/b][hr]Which is exactly why I wrote of what I prefer. Neither solution is inherently "better" than the other, except subjectively.[/quote]Ah. OK. I'll crawl back under my rock again. :blush:I misinterpreted your post as putting the case for "bigger is better". Apologies for that.[/quote]Nah. I write overlong posts, heavy on metaphore, and when someone misses some detail of it, it's hardly their fault. :-)I'm too inconsistent to hold to a specific view on the subject. Like I mentioned, I prefer a lockblade knife with just a blade over a Swiss Army knife that could be used to rebuild whole civilizations after a nuclear war. (Some of them do seem that way.) At the same time, I prefer SSMS over QA and (darn, I just went blank on what the management tool was for SQL 2000), because it does more in one place.

RE: The Flaws of Choice

majorbloodnock — Tue, 08 Dec 2009 07:03:08 GMT

[quote][b]GSquared (12/8/2009)[/b][hr]Which is exactly why I wrote of what I prefer. Neither solution is inherently "better" than the other, except subjectively.[/quote]Ah. OK. I'll crawl back under my rock again. :blush:I misinterpreted your post as putting the case for "bigger is better". Apologies for that.

RE: The Flaws of Choice

GSquared — Tue, 08 Dec 2009 06:53:33 GMT

[quote][b]majorbloodnock (12/8/2009)[/b][hr][quote][b]GSquared (12/7/2009)[/b][hr][quote][b]Steve Jones - Editor (12/7/2009)[/b][hr]I'm not sure that I agree multiple apps aren't simpler. You do have the same knowledge requirement, but when you go to perform a function, you have less clutter, and memory load, to deal with. Less to distract you, etc.I do like the Einstein quote. You want things to be simple for the user (or group of users), but you need to ensure things aren't too simple that they lose the functionality. It's trying to find the right place on a continuum, not picking among two options.[/quote]Okay, let's take apart a simple example:You want to drive from Point A to Point B for a meeting, and you don't know how to get there.Here's the integrated, Tolkein version (one app to rule them all and in the interface bind them): You open one application, let's call it Google.com, and you plug in your destination. It offers you a map of the location. In the same application, you input your origin point, and it gives you turn-by-turn directions. If it's on your smart phone, it will also tell you where you are now, and you can get restaurants along the way if you decide you want that (so you can eat before you get there), and motels along the way and at the destination if you need that. One app. All in one place. (Android's Sherpa app will do almost all of that all in one place too.)Here's the one-app-per-piece version: You pull up the destination on a map application and it shows you the street map of the location. You use another app to get turn-by-turn directions. You then have to plug those into a GPS app to get where you are now vs where you need to be next. Then you pull up yet another to work out restaurants and motels along the way and at the destination. For each app, you have to learn and use a different interface that follows different design philosophies.[/quote]Understood, but you're talking of extremes. One app (a map) is often enough for me, but I'm happy once in a while to use the power of technology to be given directions too. However, I don't have a smart phone and as far as hotels are concerned, I don't want to be marketed at (nice big icon for those places that pay most for the privilege, with the cost eventually being passed on to me). In short, your nirvana do-it-all app is too complicated for me.In contrast, the separate apps you mentioned are, indeed, complicated to use as a whole, but that's because they're too simple (or, should I say, too narrow in their target). Given the Einstein quote, one side of your example is too extensive whilst the other is oversimplified. Neither hits the balance point - for me, that is.In practice, a complex application is usually broken down anyway into screens or modules for specific purposes. Given that, there's often little difference IMHO between learning different screens of one big app vs learning separate small apps, so long as both sides are similarly intuitive.[/quote]Which is exactly why I wrote of what I prefer. Neither solution is inherently "better" than the other, except subjectively.

RE: The Flaws of Choice

majorbloodnock — Tue, 08 Dec 2009 03:53:49 GMT

[quote][b]GSquared (12/7/2009)[/b][hr][quote][b]Steve Jones - Editor (12/7/2009)[/b][hr]I'm not sure that I agree multiple apps aren't simpler. You do have the same knowledge requirement, but when you go to perform a function, you have less clutter, and memory load, to deal with. Less to distract you, etc.I do like the Einstein quote. You want things to be simple for the user (or group of users), but you need to ensure things aren't too simple that they lose the functionality. It's trying to find the right place on a continuum, not picking among two options.[/quote]Okay, let's take apart a simple example:You want to drive from Point A to Point B for a meeting, and you don't know how to get there.Here's the integrated, Tolkein version (one app to rule them all and in the interface bind them): You open one application, let's call it Google.com, and you plug in your destination. It offers you a map of the location. In the same application, you input your origin point, and it gives you turn-by-turn directions. If it's on your smart phone, it will also tell you where you are now, and you can get restaurants along the way if you decide you want that (so you can eat before you get there), and motels along the way and at the destination if you need that. One app. All in one place. (Android's Sherpa app will do almost all of that all in one place too.)Here's the one-app-per-piece version: You pull up the destination on a map application and it shows you the street map of the location. You use another app to get turn-by-turn directions. You then have to plug those into a GPS app to get where you are now vs where you need to be next. Then you pull up yet another to work out restaurants and motels along the way and at the destination. For each app, you have to learn and use a different interface that follows different design philosophies.[/quote]Understood, but you're talking of extremes. One app (a map) is often enough for me, but I'm happy once in a while to use the power of technology to be given directions too. However, I don't have a smart phone and as far as hotels are concerned, I don't want to be marketed at (nice big icon for those places that pay most for the privilege, with the cost eventually being passed on to me). In short, your nirvana do-it-all app is too complicated for me.In contrast, the separate apps you mentioned are, indeed, complicated to use as a whole, but that's because they're too simple (or, should I say, too narrow in their target). Given the Einstein quote, one side of your example is too extensive whilst the other is oversimplified. Neither hits the balance point - for me, that is.In practice, a complex application is usually broken down anyway into screens or modules for specific purposes. Given that, there's often little difference IMHO between learning different screens of one big app vs learning separate small apps, so long as both sides are similarly intuitive.

RE: The Flaws of Choice

lnoland — Mon, 07 Dec 2009 17:40:19 GMT

I generally gravitate towards the big, kitchen-sink apps, usually because I want to do things that most people, apparently, do not, or I want to do a lot more things than most and I would prefer an integrated system (or building blocks which are easy to integrate). In my experience, the biggest problem isn't when an application has a lot of options -- its when it treats them as if they are all independent, equally weighted, and lacking any organizational attributes. A good example would be any of a large number of the more powerful *NIX tools -- check out their man page or configuration files and they go on and on for pages and pages of parameters, often in no particular order, and with no or limited indcation of how one might use them. (Try reading the configuration files and man pages for the Amanda backup utility sometime when you have a few years free).The idea of having a default configuration which matches the needs of the majority of users is a good one, but I would take it one step further. A flexible tool ought to have a group of templates each of which represents a configuration optimized for one of a number of popular use modes with documentation or interactive assistance in choosing among them. A similar, but even better, approach is to have configuration involve an interactive interview process in which the tool accurately determines the user's desires for using the app and configures the app to suit. Individual options should still be available via menus and such for quick changes by the well-informed user, but the initial configuration should, at least optionally, be based upon the interview process. Tax programs have used this type of approach, for years, to try to simplify the complex process of assembling and filling out the myriad tax forms based upon the needs of a given situation, though they often do it rather badly, probably due to the fact that frequent changes, low prices, and a short sales cycle do not make it cost effective to do a much better job.Ultimately, I think our computers should work for us -- but I do not think we should limit that to just the apps's primary purpose. Apps should also help us to use them more effectively. If that is hard to program it is probably because we don't do it enough.-- Les

RE: The Flaws of Choice

James Stover — Mon, 07 Dec 2009 14:40:45 GMT

I prefer the KISS philisophy - Keep It Simple, Stupid. Complexity just makes me sleepy.

RE: The Flaws of Choice

sknox — Mon, 07 Dec 2009 12:58:36 GMT

[quote]When we build an application, or even work with a platform like SQL Server, what' s the right balance between simplicity and choice? I'm not sure, but I think that the model changes for each person, and we want to include the level of choice that makes someone use the product efficiently, but with the least amount of options.'[/quote]Alternately, you could say that because the model changes for each person, apps should be flexible, with a default configuration that is close to the average user's need, but the options and ability to be configured for even simpler or even more complex scenarios. That's how I write my SSRS reports - I often include several parameters (based on the users' needs) but I try to default* them to the common usage scenario.My ideal application has two buttons on its main screen: "Go" and "Advanced Options" :-D . * Well, I often won't default one parameter, because SSRS has a nasty habit of automatically running reports if all parameters have defaults. Cute, but it can be a headache if the report takes 2-3 minutes to run and you didn't want the default information.

RE: The Flaws of Choice

MattieNH — Mon, 07 Dec 2009 10:50:38 GMT

I haven't read this [url] http://www.amazon.com/Paradox-Choice-Why-More-Less/dp/0060005688/ref=sr_1_1?ie=UTF8&s=books&qid=1260207811&sr=1-1#noop[/url], but I've heard the author interviewed. It might have the answers you're lookin for.Mattie

RE: The Flaws of Choice

Matt Miller (#4) — Mon, 07 Dec 2009 10:45:43 GMT

[quote][b]Steve Jones - Editor (12/7/2009)[/b][hr]Is a hot dog cooker inefficient? Having one means that my kid might be able to cook something without help. It might seem like a waste to a chef, but that doesn't mean it's wrong. Don't chefs have multiple knives for different purposes, each being a separate "app" for a separate purpose?You can take it too far, and I might agree that a hot dog cooker is a little specialized, but not necessarily. It could fit the situation.[/quote]To take this specific example: the hot dog cooker isn't necessarily inefficient for the specific purpose at hand, but - it probably represents an inefficient use of space. This would have to live on the counter somewhere, be plugged into an outlet (taking that outlet out of circulation), another manual to read, another warrantly to keep up to date, etc... So - you could make a choice to put one or two of these "single use" items on your kitchen counter, but I doubt you'd have the space for the 200+ specific cookers you would need to deal with every single specialized cooking option.The same with our application: the right approach is to find the "high-value targets" for single use apps which give you the best output, and then rely on multi-purpose apps to deal with a lot of the other scenarios. The integration complexities alone grow exponentially as you add in more "moving parts".

RE: The Flaws of Choice

Carlos Bossy — Mon, 07 Dec 2009 10:00:13 GMT

Marketing, packaging, competition and cost drives the way Chipotle, Subway and Microsoft put together their products. The user is only one factor in the equation. When we develop apps, the same is often true. Applying this to SQL Server, how many people use it as a only a relational database engine? Or use less than 20% of the features? I would say most.However, as a consultant who architects solutions for clients that include a relational DB, a data warehouse, ETL, cubes, data mining, and reporting, then I'm happy to have all the solutions I need under one product line. This makes it much easier and cheaper than bringing together a number of different apps.

RE: The Flaws of Choice

GSquared — Mon, 07 Dec 2009 09:45:33 GMT

[quote][b]Steve Jones - Editor (12/7/2009)[/b][hr]I'm not sure that I agree multiple apps aren't simpler. You do have the same knowledge requirement, but when you go to perform a function, you have less clutter, and memory load, to deal with. Less to distract you, etc.I do like the Einstein quote. You want things to be simple for the user (or group of users), but you need to ensure things aren't too simple that they lose the functionality. It's trying to find the right place on a continuum, not picking among two options.[/quote]Okay, let's take apart a simple example:You want to drive from Point A to Point B for a meeting, and you don't know how to get there.Here's the integrated, Tolkein version (one app to rule them all and in the interface bind them): You open one application, let's call it Google.com, and you plug in your destination. It offers you a map of the location. In the same application, you input your origin point, and it gives you turn-by-turn directions. If it's on your smart phone, it will also tell you where you are now, and you can get restaurants along the way if you decide you want that (so you can eat before you get there), and motels along the way and at the destination if you need that. One app. All in one place. (Android's Sherpa app will do almost all of that all in one place too.)Here's the one-app-per-piece version: You pull up the destination on a map application and it shows you the street map of the location. You use another app to get turn-by-turn directions. You then have to plug those into a GPS app to get where you are now vs where you need to be next. Then you pull up yet another to work out restaurants and motels along the way and at the destination. For each app, you have to learn and use a different interface that follows different design philosophies.May sound silly, but in the late 90s, I got a CD-based database of street addresses. Could look up just about any address in the US and get a map of the location. Definitely didn't do turn-by-turn. But another application I had at that time could do turn-by-turn, but only to intersections, not to addresses. Neither could look up restaurants or motels, but online yellow pages could do that by radius around an address or intersection. And GPS at that time was pretty much "here you are", without the ability to tell you where to go next or anything like that. That's 10 years ago, and it's almost exactly what I'm describing.Why don't those databases and applications get used any more (some of them don't even exist any more)? Because they weren't all-in-one, one-stop-shops. They weren't convenient to use compared to Google.com (or MapQuest or Bing or whatever else is in use these days).I like integrated solutions. I also shop for books on Amazon, instead of at specialty bookstores (do those even exist any more?). I shop at Target instead of specialty shops. I shop at a grocery store, and don't go to a butcher, then a bakery, then a greengrocer, etc.Do I need to make more decisions or less, do I have more or less options, if I shop at Target, or if I go to a video store, then a music store, then a hardware store, then an electronics store, then a clothing store, then a shoe store, then a basic grocery store, then an appliances store, then an office supplies store, et al, ad infinitum? Of course I have less options at Target. I have far fewer decisions to make. And if I shopped around, I'd probably get better goods at a better price on average. On the other hand, I'd spend more on gas, I'd have to learn my way around a dozen stores (or more), I'd have to hang onto more receipts and organize them more carefully, I'd have to pay attention to more data on sales and specials and product availability.I pay the price of convenience. But I also get to take advantage of it. I only have to learn my way around one store. I only need one set of coupons. I keep one receipt. I then spend all the time freed up that way on other things.That's the way I see it. Integration makes me more efficient, at a certain cost.As already mentioned, in some areas, I prefer specialized tools, others I prefer integrated tools. I don't use a Swiss Army knife. I do use Management Studio. Different situations, different costs, different benefits. So I have options, and I make decisions.

RE: The Flaws of Choice

Steve Jones - SSC Editor — Mon, 07 Dec 2009 09:36:04 GMT

Is a hot dog cooker inefficient? Having one means that my kid might be able to cook something without help. It might seem like a waste to a chef, but that doesn't mean it's wrong. Don't chefs have multiple knives for different purposes, each being a separate "app" for a separate purpose?You can take it too far, and I might agree that a hot dog cooker is a little specialized, but not necessarily. It could fit the situation.

RE: The Flaws of Choice

jay-h — Mon, 07 Dec 2009 09:21:30 GMT

TV chef Alton Brown has a personal vendetta against single use appliances (hot dog cooker, for example). To degree that also applies to apps. There are exceptions, but an app just to do one single thing is kind of inefficient.

RE: The Flaws of Choice

Alan Vogan — Mon, 07 Dec 2009 09:21:22 GMT

Interesting observation Steve. And some interesting posts by everyone. I especially liked the comments from blandry and Ron. How simple do we make it? When is it a business procedure that needs to be changed(enforced!) or a design change? How smart do we want the user to be?Around here, unless you're bilingual (which I am on a limited basis), you get to order a Burrito, Taco, or Torta (that's sandwich for most of you...). I find my user experience depends on my server. If they know me, I'll order in English, knowing I'll get a nice fat burrito with everything. However, if they don't know me, I order in Spanish, because if I order in English, they'll assume when I say 'everything', I'm a gringo and didn't really want the salsa rojo, jalapenos, onions and cilantro, just the meat, cheese and salsa verde.Relating to software design, I guess I've been put into 2 users groups, where I can have power-user access if I choose to use it.

RE: The Flaws of Choice

Steve Jones - SSC Editor — Mon, 07 Dec 2009 09:11:58 GMT

I tend to agree that Subway, and Chipotle, have a few issues. You do have to spell things out everytime, which is annoying for someone like me that tends to get the same thing every time. It would be great if they had a card that saved my prefs I could scan when I walked up. Have them just build the order.I do have the iPhone Chipotle app and need to try that out. Maybe Wed when I run the kids down for karate and tutoring.I think the issue that some people have a McDs or other places isn't that they don't know the menu, it's that they aren't sure what they want. They're looking around to figure out what they feel like. I know that drives me crazy, and if we are going through somewhere, I tell the kids they better have decided BEFORE I get to the drive thru.

RE: The Flaws of Choice

Steve Jones - SSC Editor — Mon, 07 Dec 2009 08:37:46 GMT

I'm not sure that I agree multiple apps aren't simpler. You do have the same knowledge requirement, but when you go to perform a function, you have less clutter, and memory load, to deal with. Less to distract you, etc.I do like the Einstein quote. You want things to be simple for the user (or group of users), but you need to ensure things aren't too simple that they lose the functionality. It's trying to find the right place on a continuum, not picking among two options.

RE: The Flaws of Choice

Carla Wilson-484785 — Mon, 07 Dec 2009 08:22:46 GMT

Ok, while I can order at Chipotle fairly quickly, I admit I am the person in the burger joint who has to read the whole menu (oh, isn't there anything on this menu that I really want?)... which gave me the idea that maybe there could be an express lane and a "don't know what you want" lane, so the people who know exactly what they want ("the No. 3, super-size me") can move on.Which made me think about the number of applications I have written, where 90% of my users get a limited number of choices but a small number of users get additional choices, based on their user group assignment.

RE: The Flaws of Choice

GSquared — Mon, 07 Dec 2009 07:50:39 GMT

Having one app for each choice doesn't actually reduce the number of decisions to make, it just increases the number of apps you need to learn how to use. And if they don't have nearly identical interfaces, it increases the learning curve for mastering them all.

RE: The Flaws of Choice

DEK46656 — Mon, 07 Dec 2009 07:42:49 GMT

As it applies to software, I think the early UNIX days work as an example. Each utility addressed a single individual problem, and did it very well. The true advantage came from the fact that they could work with each other via the shell. Many times I would take several utilities to perform some ETL, wrap the whole thing in a KSH script, and have exactly what was needed as an “app”.Applying this to the restaurant example: order a number 2 combo and be done with it.

RE: The Flaws of Choice

george sibbald — Mon, 07 Dec 2009 06:59:00 GMT

sounds like the old 80\20 rule.For any given piece of kit\app we use we only use 20% of its functionality 80% of the time. Hence the popularity of netbooks recently.Myself, I used to be indecisive, now I'm not so sure. :-)

RE: The Flaws of Choice

jay-h — Mon, 07 Dec 2009 06:52:18 GMT

too many options is often a prodduct of bad design.Either the designer does not understand how the user is using the product, or is basically lazy to find out. There is nothing wrong with flexibility, but there should be a basic default and if there is a need to deviate from that, the process should be straightforward.I have that problem with Subway. The food is decent, but you can't simply order a sandwich. You need to go through a checklist, bread, meat, cheese, condiments.... etc. Nice to have choice but a pain to have to spell it out every time.

RE: The Flaws of Choice

Ron Cicotte — Mon, 07 Dec 2009 06:46:12 GMT

Einstein gave us good advice when he said:"Everything should be made as simple as possible, but not one bit simpler".Design is an exercise in making things only as complex as the functionality requires. Finding the right balance is central to the art of programming.

RE: The Flaws of Choice

blandry — Mon, 07 Dec 2009 06:33:16 GMT

During the years the great physicist and futurist Arno Penzias worked at Bell Labs, he penned a diatribe on the increasing complexity of systems and how that would eventually limit knowledge and mankind in general. That is, as systems (hardware, software, restaurant menus, etc) became more and more complex, fewer and fewer people would fully understand the systems, and knowledge would become so 'pigeon holed' that we would in essence, become further and further limited in our ability to grasp systems.If you look at computing when I started in the late 70's, you had to know everything; hardware, programming, database, calculations, formulas - you name it. Now? Now we have DBAs who are great at database, but know very little about programming. We have programmers who crunch code, but don't understand database. We have specialists who are "experts" at one small corner of something, but cannot fathom related subject matter.When I was growing up McDonalds had two sandwiches - hamburger and cheeseburger. Now, they have what, 15 of them, and yet what are they? Basically the same sandwich just rearranged with some extra (lettuce, tomato, etc) thrown in.I would agree with the tenet of the Flaws of Choice, but I would also argue the point Penzias made...We are become more and more "stupid" by our own choice to overcomplicate even the most simple things, all in the name of selling you something. And that applies for software, hardware, cars, electronics, and yes, fast food joints.In short, we are building our own "Idiocrasy".

RE: The Flaws of Choice

Jason Miller-476791 — Mon, 07 Dec 2009 05:05:04 GMT

When was the last time McDonald's changed their menu? It still amazes and frustrates me when I go into some established national chain for a quick bite, and end up behind someone who acts as if they were just dragged out of the bronze age...This goes back to the discussion of making a choice. Make a choice, right or wrong, make a choice. Indecision is sometimes much worse.I'm hungry now (thanks Steve), anyone got some waffles?

RE: The Flaws of Choice

majorbloodnock — Mon, 07 Dec 2009 03:37:32 GMT

[quote]When we build an application, or even work with a platform like SQL Server, what' s the right balance between simplicity and choice? I'm not sure, but I think that the model changes for each person, and we want to include the level of choice that makes someone use the product efficiently, but with the least amount of options.'[/quote]Not sure I agree entirely with that one. Given most of us who build apps or work with SQL Server do so in a business environment (at least I assume so, and I know how dangerous assumptions can be...), I'd suggest the right model isn't what's optimum for any particular person, but what's right for the business as a whole. In many cases, the two'll be about the same, but there are significant differences.For instance, changing a screen may only require an extra second of a user's time and add lots of functionality, but if most of the users are part of a call centre, that extra second per call can easily be a big bad no-no for the business as a whole.Therefore, I agree entirely that paying attention to usability as well as outright functionality is an often forgotten priority, but it's also worth recognising the hierarchy of whose needs are most important to fulfil

The Flaws of Choice

Steve Jones - SSC Editor — Sun, 06 Dec 2009 20:32:57 GMT

Comments posted to this topic are about the item [B]The Flaws of Choice[/B]