December 7, 2009 at 9:45 am
Steve Jones - Editor (12/7/2009)
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.
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.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 7, 2009 at 10:00 am
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.
LinkedIn - http://www.linkedin.com/in/carlosbossy
Blog - http://www.carlosbossy.com
Follow me - @carlosbossy
December 7, 2009 at 10:45 am
Steve Jones - Editor (12/7/2009)
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.
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".
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
December 7, 2009 at 10:50 am
I haven't read this 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%5B/url%5D,
but I've heard the author interviewed. It might have the answers you're lookin for.
Mattie
December 7, 2009 at 12:58 pm
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.'
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" 😀 .
* 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.
December 7, 2009 at 2:40 pm
I prefer the KISS philisophy - Keep It Simple, Stupid. Complexity just makes me sleepy.
James Stover, McDBA
December 7, 2009 at 5:40 pm
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
December 8, 2009 at 3:53 am
GSquared (12/7/2009)
Steve Jones - Editor (12/7/2009)
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.
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.
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.
Semper in excretia, sumus solum profundum variat
December 8, 2009 at 6:53 am
majorbloodnock (12/8/2009)
GSquared (12/7/2009)
Steve Jones - Editor (12/7/2009)
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.
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.
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.
Which is exactly why I wrote of what I prefer. Neither solution is inherently "better" than the other, except subjectively.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 8, 2009 at 7:03 am
GSquared (12/8/2009)
Which is exactly why I wrote of what I prefer. Neither solution is inherently "better" than the other, except subjectively.
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.
Semper in excretia, sumus solum profundum variat
December 8, 2009 at 7:18 am
majorbloodnock (12/8/2009)
GSquared (12/8/2009)
Which is exactly why I wrote of what I prefer. Neither solution is inherently "better" than the other, except subjectively.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.
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.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 8, 2009 at 7:27 am
GSquared (12/8/2009)
... (darn, I just went blank on what the management tool was for SQL 2000)...
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
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
December 8, 2009 at 9:10 am
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.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
December 8, 2009 at 9:31 am
Steve Jones - Editor (12/8/2009)
GSquared (12/8/2009)
... (darn, I just went blank on what the management tool was for SQL 2000)...
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
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.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 9, 2009 at 12:04 pm
jay holovacs (12/7/2009)
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.
Subway must not travel well...the food is decent???
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 16 through 29 (of 29 total)
You must be logged in to reply to this topic. Login to reply