Not to kick a dead horse, or repeat my other post here, but one of things I appreciate greatly about Apple's products is the true design- centric approach to interfaces, as is demonstrated in their software apps and hardware such as the iPod and iPhone. The install / uninstall situation on Macs is unarguably out of step with this philosophy. The majority of users care about two things: "installed" or "uninstalled". An installation should be literally a license acceptance, and confirm install, nothing more. Every other variation or tweak to an install should be hidden behind an "Options" or "Advanced" button in the install.

Apple does a great job of distilling of their UIs down to only typical end-users need 80% of the time, and leaving the other details hidden, but accessible when necessary. Installation is desperately in need of the same simplicity and consistency, and uninstallers are needed as part of a standard framework so that I don't have to lead Mom through "delete your prefs files" and "navigate to Application support..." scavenger hunts.

B

On Sep 10, 2008, at 10:47 AM, David wrote:

Dragging an application to "Applications" may seem hard or unusual to
a user the 1st time they ever install an application on the Mac, but
after that its the assumed way to install applications.

Consistency is a big deal. Apple should define and enable some
consistent application installation models. Dragging an application to
"Applications" is fine since that has been the convention and many
applications perform their install in this fashion.

Unfortunately, I think Apple is making this space ripe for confusion
by not providing easy tools nor documentation on how to work with
DMGs. Most applications require acceptance of a license agreement.
Having outdated documentation referring to tools which can no longer
be run adds to the confusion.

If the convention is to manually install by dragging the app to
'Applications', and if the convention is to use a DMG which shows the
application and 'Applications' so you can more easily drag it.... then
Apple should provide an easy way to create such a DMG.

As far as I understand it, you need to come up with your own graphics
for a custom background, then somehow fiddle with the location of your
application and Applications alias to make it work.


On Wed, Sep 10, 2008 at 10:32 AM, Bill Royds <[EMAIL PROTECTED]> wrote:

On 10-Sep-08, at 04:59 , [EMAIL PROTECTED] wrote:

Anyway, if Mac software starts heading back down the road to everything having an installer, the appeal of the Mac platform vs. Windows will be severely diminished in my eyes. Drag and drop puts the user in control - installers put the user at their mercy. Whenever I see an installer that does nothing but put an app in /Applications, I tend to think twice about using that app, because it's often a sign of a poorly thought out product. Often I will send an e-mail to the author complaining about this as well.


But you are not a typical user so your preferences are not the most
important.

Most users who want to install software only want to b able to click on the downloaded package and have it install.It might ask some questions like password or ask whether you want advanced control, but even the concept of
moving to /Applications is more than most users want to know.
Windows installers are much easier for naive users to handle than anything that requires knowledge of the system structure such as drag and drop to
/Applications.

Of course, it is still better to have a simple install logic and a bundled app that you could drag and drop to /Applications is better than one that requires many different steps. probably the double click on an app package
should just invoke a shell script the\at does
sudo cp MyApp.app /Applications

with the sudo password prompt in a gui window.



_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/enki1711%40gmail.com

This email sent to [EMAIL PROTECTED]

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/brado%40neurofire.com

This email sent to [EMAIL PROTECTED]

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to