While I can appreciate the "purity of design" of not needing an installer/just drag'n'drop the app, I don't think we need to eschew installers entirely. No doubt that anyone here feels perfectly adept to drag the app wherever they wish onto their HD and call it a day. However, we are forgetting the "uber-casual" user and those who know nothing about computers and don't want to know. For them, they would want an installer to place the file for them. It may seem like a trivial operation, but there are people who just don't want to have any hand in it, if they can help it. I think if Mac OS is to retain its aire of user friendliness to the least of the technically inclined, then an installer should be perfectly acceptable, whether or not it is as simple as moving a package to the Applications folder. Installers do have a place, imo (though personally, I am fine with installing apps in either manner).
Yet, I think most people would be fine with dragging a *file* somewhere, no?
Applications have this 'air of mystery' about them *because* of installers. Remove the mystery, make it just another file, and people will know precisely what to do with it. The nervousness is just training on bad approaches to installing apps coming to the fore.
"That's *ALL*?" is a sign of *good* design.
There are definitely some situations where an installer is needed, IMO, such as placing anything in a Library. Most users won't know what the heck to do with such stuff, so do it for them. Plain apps though, those are easy.
Yet, I think most people would be fine with dragging a *file* somewhere, no?
Applications have this 'air of mystery' about them *because* of installers. Remove the mystery, make it just another file, and people will know precisely what to do with it. The nervousness is just training on bad approaches to installing apps coming to the fore.
"That's *ALL*?" is a sign of *good* design.
There are definitely some situations where an installer is needed, IMO, such as placing anything in a Library. Most users won't know what the heck to do with such stuff, so do it for them. Plain apps though, those are easy.
I know it seems like a fundamental procedure that anyone who is working on a computer should be able to click and drag. However, that is an expectation, not a certain cosmic reality. Drag it to where? Why not just doubleclick on it right from the image? Why is my app gone after I logged off? I was just running it- hence, I thought it was now on my computer. Why can't I drag the icon straight to the root directory (that thingy that looks like my HD- isn't that where my things are stored)?
Suffice to say, any number of things can occur between "it's easy enough to just drag it" and "what the most clueless user will try". Some amount of automation (an installer) could circumvent that, rather relying on an expectation that the user can handle what you and I find rather trivial.
True, but the same questions will be asked about a file inside an image, right?
"Why can't I open it again, I had it before!" "Why can't I drag the file to the hard drive thingy..."
Teach them about *files* and how they interact with disk images, and they will know how to handle applications too. Since working with files is pretty basic, I don't see how it's a big leap from there to application files. \
My only real concern is that whole uninstall-as-thou-didst-install thing. The user has to remember that they used an installer. Why not tag the application bundle with 'installed by installer', and when it's dragged to the Trash, provide a message to the user? "This application was installed by using an installer. It is recommended that you use the uninstall of the installer to thoroughly remove all traces of this application from your system. If you wish to only remove this application, and leave other possible files installed, you may do so. (Use Uninstaller) (Remove App Only) (Cancel)" An alias to the installer package can also be embedded, so the system can find it unless it's been deleted.
Ideally, if you drag an app to the trash, its associated files it installed (prefs, anything it put in the Library folder, etc.) should tag along for the ride. AFAIK, this won't cause ay so-called DLL hell scenarios even now. If it does, well, ideally you'd find a way to deal with that as well. The end result appears as clean and simple and logical as possible to the user even if the programmers have to jump through hoops, assuming it doesn't screw with a bunch of other stuff in the long run.
Well ideally, it would warn the user that is was about to trash a bunch of other stuff first and let them opt out of it. You may want to delete the app (corruption), but leave other files (prefs) intact. The installer may need to do some mojo (shut down services) before letting the files be removed. Or other scenarios. An installer could let the system know what files it installed (we have this in Receipts for some installed things), and whether or not it was safe to 'just delete'. *Then* the logic could be in the Finder, but it may be easier just to have installer leave an uninstall script behind in the Receipt, and give the user the option of using it.
True, but the same questions will be asked about a file inside an image, right?
Actually, that is the scenario I was premising those questions against. You never know what level of file saavy the user will have. Maybe they know what to do with the file, maybe not. Therein lies all sorts of potential responses which would boggle you and I as to what mental process had to occur that possessed them to do what they did. I wouldn't go so far as to say we should have "wizards" to automate anything and everything for the user (er, like Windows), but I don't think a simple installer to placate newbies is so out of line. I am also in agreement with you that installers are really not a necessity for OSX. All I am saying that is that they still can offer benefits to a particular group of users (ones that should not necessarily be ignored or dismissed due to their lack of knowledge of computer "stuff").
I think they should use labels automatically for those programs that have an uninstaller. They can use Red for those with an uninstaller and Green for those without an uninstaller. For those that don't need that and can take of themselves without automation, there could be a little preference dialog in System Preferences where they could turn this off.
Right, but what I'm pointing out (perhaps not well) is that the fewer inconsistencies you can make in a system, the better. If a user can't handle a file in an image, then they haven't a prayer of figuring out an installer in an image, IMO. Teach them how to deal with files in images, and you've just given them a powerful bit of information for working with the system in general.
Now leverage that for applications, and you've removed one more thing they have to remember.
Wizards are a hack around bad UI behaviours. "Oh well, we can't figure out how to make this simple, so we'll just hand hold the user." :P It's a lazy developer's way out.
What I'd rather see is a dynamic tutorial. The first time a user mounts an image, for instance, a Help dialog can pop up (noooooo! No Clippy! ) offering to give them a quick tutorial on what it is, how it works, and what they can do with it. *NOT* do it for them, but instead give them solid information that they can use. Benefit is also that they user knows that the system has that info in it, so they can know to go looking for it later.
I really wish Apple shipped a simple tutorial with the system like they used to. \
Right, but what I'm pointing out (perhaps not well) is that the fewer inconsistencies you can make in a system, the better. If a user can't handle a file in an image, then they haven't a prayer of figuring out an installer in an image, IMO.
Actually, the reverse should be true (barring a clearly poorly thought out installer). The simplest behavior to count on is that they will attempt to doubleclick on something until something happens. If you doubleclick on a file in an image, the application will probably start, but the user still will not have accomplished a successful installation. The app is gonna disappear once the image dismounts (for one reason or other, eventually). Then they will wonder where that app went next time and have to start over with doubleclicking the image, etc. ...or they know they got to drag it somewhere, but they are not certain where is a "good" spot. Maybe it "won't go" where they think it is supposed to go... Maybe they are even unsure about "click-dragging"... Maybe they would rather not move it somewhere, under the rationale that if they found it there, maybe that is where it belongs (who am I to move it somewhere?)... Maybe they get the bright idea to drag the icon to their proxy panel (since they know they will be using it soon)?...(it'll work once, until that image dismounts at next logoff) All sorts of maybe's, and only one reason to know that will give them the correct response...
Doubleclicking on an installer within an image, will result in the installer beginning the installing process. There is no ambiguity there. It's obvious it isn't the app running, and they are currently in an installation track (sit back, keep pressing the OK button, and let it do its thing). Click install to the default location, and a successful install is nearly guaranteed. All that is needed next is a little message telling the user to look for the app in their applications folder (or wherever), and/or start it up automatically, if that helps at all.
What happens if they double-click on a *DOCUMENT* file on an image?
Same exact confusion. It works, but it's not on their computer next time they go to get it.
There's no way around that problem short of user education. (What are you going to do, have an 'installer' ask them where they want to put it?) So if you are educating users anyway on how to work with images, then having applications be just another file is *already handled*.
Principle of least surprise + minimalist learning curve
Install a document??? Not really the end of the world, imo... I think that is getting to opening a whole new can of worms when you start making comparisons of installing applications vs."installing documents" (even though the user may do the same click-drag with either of them). Why would you even have a document in an image, other than to keep it data-compressed? If that is the case, then maybe you should leave it as an image, rather than drag out your own expanded copy.
Users will encounter files and applications on remote and other removable volumes. This includes disk images.
Opening a file on a removable volume is a fairly basic task for most users. They need to understand that if the volume 'goes away' for any reason, that they no longer have access to the file. It doesn't matter what the file is, it still applies. If they want it around 24/7, they have to copy it to their local drive.
If an application is treated just like any other file, then once they learn the above, they also learn how to 'install' applications on their local drive. It becomes something they already know how to do for simple things like document files.
In such cases, an installer isn't needed - it becomes transparent to the user, and a natural extension of what they already know concerning removable volumes, be they CDs, network mounts, or disk images.
Treat disk images just like any other removable volume. Treat applications just like any other file. Suddenly the user has to learn a lot less.
There will be specific cases where installers will be useful, but those should be the *exception*, not the rule. If they're the rule, you've screwed up on your basic OS design.
Heres' the key to our disconnect- no one is arguing that installers should be a necessity. No one is arguing that appreciating the relevance of click-drag is irrelevant. Those precepts are all good things to base an OS. In the same light, it does not mean you are barred from appreciating the automation perks of an intaller (nor does it imply that someone who advocates installers is advocating that everything incorporate them). It does not diminish "teh bragging rights" of the OS. It is still as elegant as it was before, in not "needing" said installlers to accomplish what is needed in other "lesser" OS's. ...Because that is essentially what is being argued here- bragging rights. It is important for some that installers do not proliferate in OSX, because how then could they claim that it does not need them? For the rest of us- who really cares? What will be more important is flexibility. Do it the way you want, and the OS is such that it will let you get the work done in the manner you choose.
I think you and I can agree that we will never see eye to eye on this matter. I think both of us have presented compelling cases. I am certainly willing to concede that this is a matter that really does have 2 sides, not just only one way can be the right way. Can you?
*shrug* Sure. I hardly see it as being something as trivial and petty as bragging rights, but if that's your viewpoint, you're right, we're never going to see eye to eye, and it's best to just drop it.
It took me sometime to get used to this, being to used to the Windows world, however, I have noticed a few problem apps and wonder if anyone has any advice.
I installed an app that adds an extension to system preferences and also menu entries in the finder, the app has no uninstaller so how do you get rid of it without reinstalling the OS. Help is greatly appreciated
It took me sometime to get used to this, being to used to the Windows world, however, I have noticed a few problem apps and wonder if anyone has any advice.
I installed an app that adds an extension to system preferences and also menu entries in the finder, the app has no uninstaller so how do you get rid of it without reinstalling the OS. Help is greatly appreciated
Try right-clicking (control-clicking) the Preference Pane icon. If that doesn't show a "Remove" menu item, navigate to ~/Library/PreferencePanes and see if it is there. Or it could be in /System/Library/PreferencePanes or /Library/PreferencePanes.
The Finder menu items are more of a problem. If it really hacked the Finder, you'll need to reinstall.
Comments
Originally posted by Kickaha
Yeah, just in case Relic's 'Not the face! Not the face!' wasn't enough, what he suggested will delete your entire drive, every file, no warning.
Bad Relic. No biscuit.
Applications have this 'air of mystery' about them *because* of installers. Remove the mystery, make it just another file, and people will know precisely what to do with it. The nervousness is just training on bad approaches to installing apps coming to the fore.
"That's *ALL*?" is a sign of *good* design.
There are definitely some situations where an installer is needed, IMO, such as placing anything in a Library. Most users won't know what the heck to do with such stuff, so do it for them. Plain apps though, those are easy.
Originally posted by Kickaha
Yet, I think most people would be fine with dragging a *file* somewhere, no?
Applications have this 'air of mystery' about them *because* of installers. Remove the mystery, make it just another file, and people will know precisely what to do with it. The nervousness is just training on bad approaches to installing apps coming to the fore.
"That's *ALL*?" is a sign of *good* design.
There are definitely some situations where an installer is needed, IMO, such as placing anything in a Library. Most users won't know what the heck to do with such stuff, so do it for them. Plain apps though, those are easy.
I know it seems like a fundamental procedure that anyone who is working on a computer should be able to click and drag. However, that is an expectation, not a certain cosmic reality. Drag it to where? Why not just doubleclick on it right from the image? Why is my app gone after I logged off? I was just running it- hence, I thought it was now on my computer. Why can't I drag the icon straight to the root directory (that thingy that looks like my HD- isn't that where my things are stored)?
Suffice to say, any number of things can occur between "it's easy enough to just drag it" and "what the most clueless user will try". Some amount of automation (an installer) could circumvent that, rather relying on an expectation that the user can handle what you and I find rather trivial.
"Why can't I open it again, I had it before!" "Why can't I drag the file to the hard drive thingy..."
Teach them about *files* and how they interact with disk images, and they will know how to handle applications too. Since working with files is pretty basic, I don't see how it's a big leap from there to application files.
My only real concern is that whole uninstall-as-thou-didst-install thing. The user has to remember that they used an installer. Why not tag the application bundle with 'installed by installer', and when it's dragged to the Trash, provide a message to the user? "This application was installed by using an installer. It is recommended that you use the uninstall of the installer to thoroughly remove all traces of this application from your system. If you wish to only remove this application, and leave other possible files installed, you may do so. (Use Uninstaller) (Remove App Only) (Cancel)" An alias to the installer package can also be embedded, so the system can find it unless it's been deleted.
That's just my two cents on it though.
Originally posted by Kickaha
True, but the same questions will be asked about a file inside an image, right?
Actually, that is the scenario I was premising those questions against. You never know what level of file saavy the user will have. Maybe they know what to do with the file, maybe not. Therein lies all sorts of potential responses which would boggle you and I as to what mental process had to occur that possessed them to do what they did. I wouldn't go so far as to say we should have "wizards" to automate anything and everything for the user (er, like Windows), but I don't think a simple installer to placate newbies is so out of line. I am also in agreement with you that installers are really not a necessity for OSX. All I am saying that is that they still can offer benefits to a particular group of users (ones that should not necessarily be ignored or dismissed due to their lack of knowledge of computer "stuff").
Now leverage that for applications, and you've removed one more thing they have to remember.
Wizards are a hack around bad UI behaviours. "Oh well, we can't figure out how to make this simple, so we'll just hand hold the user." :P It's a lazy developer's way out.
What I'd rather see is a dynamic tutorial. The first time a user mounts an image, for instance, a Help dialog can pop up (noooooo! No Clippy!
I really wish Apple shipped a simple tutorial with the system like they used to.
Originally posted by Kickaha
Right, but what I'm pointing out (perhaps not well) is that the fewer inconsistencies you can make in a system, the better. If a user can't handle a file in an image, then they haven't a prayer of figuring out an installer in an image, IMO.
Actually, the reverse should be true (barring a clearly poorly thought out installer). The simplest behavior to count on is that they will attempt to doubleclick on something until something happens. If you doubleclick on a file in an image, the application will probably start, but the user still will not have accomplished a successful installation. The app is gonna disappear once the image dismounts (for one reason or other, eventually). Then they will wonder where that app went next time and have to start over with doubleclicking the image, etc. ...or they know they got to drag it somewhere, but they are not certain where is a "good" spot. Maybe it "won't go" where they think it is supposed to go... Maybe they are even unsure about "click-dragging"... Maybe they would rather not move it somewhere, under the rationale that if they found it there, maybe that is where it belongs (who am I to move it somewhere?)... Maybe they get the bright idea to drag the icon to their proxy panel (since they know they will be using it soon)?...(it'll work once, until that image dismounts at next logoff) All sorts of maybe's, and only one reason to know that will give them the correct response...
Doubleclicking on an installer within an image, will result in the installer beginning the installing process. There is no ambiguity there. It's obvious it isn't the app running, and they are currently in an installation track (sit back, keep pressing the OK button, and let it do its thing). Click install to the default location, and a successful install is nearly guaranteed. All that is needed next is a little message telling the user to look for the app in their applications folder (or wherever), and/or start it up automatically, if that helps at all.
What happens if they double-click on a *DOCUMENT* file on an image?
Same exact confusion. It works, but it's not on their computer next time they go to get it.
There's no way around that problem short of user education. (What are you going to do, have an 'installer' ask them where they want to put it?) So if you are educating users anyway on how to work with images, then having applications be just another file is *already handled*.
Principle of least surprise + minimalist learning curve
One last ditch try.
Users will encounter files and applications on remote and other removable volumes. This includes disk images.
Opening a file on a removable volume is a fairly basic task for most users. They need to understand that if the volume 'goes away' for any reason, that they no longer have access to the file. It doesn't matter what the file is, it still applies. If they want it around 24/7, they have to copy it to their local drive.
If an application is treated just like any other file, then once they learn the above, they also learn how to 'install' applications on their local drive. It becomes something they already know how to do for simple things like document files.
In such cases, an installer isn't needed - it becomes transparent to the user, and a natural extension of what they already know concerning removable volumes, be they CDs, network mounts, or disk images.
Treat disk images just like any other removable volume. Treat applications just like any other file. Suddenly the user has to learn a lot less.
There will be specific cases where installers will be useful, but those should be the *exception*, not the rule. If they're the rule, you've screwed up on your basic OS design.
I think you and I can agree that we will never see eye to eye on this matter. I think both of us have presented compelling cases. I am certainly willing to concede that this is a matter that really does have 2 sides, not just only one way can be the right way. Can you?
I installed an app that adds an extension to system preferences and also menu entries in the finder, the app has no uninstaller so how do you get rid of it without reinstalling the OS. Help is greatly appreciated
Originally posted by ulmo
It took me sometime to get used to this, being to used to the Windows world, however, I have noticed a few problem apps and wonder if anyone has any advice.
I installed an app that adds an extension to system preferences and also menu entries in the finder, the app has no uninstaller so how do you get rid of it without reinstalling the OS. Help is greatly appreciated
Try right-clicking (control-clicking) the Preference Pane icon. If that doesn't show a "Remove" menu item, navigate to ~/Library/PreferencePanes and see if it is there. Or it could be in /System/Library/PreferencePanes or /Library/PreferencePanes.
The Finder menu items are more of a problem. If it really hacked the Finder, you'll need to reinstall.