Re: Cocoa-dev Digest, Vol 5, Issue 1598
Re: Cocoa-dev Digest, Vol 5, Issue 1598
- Subject: Re: Cocoa-dev Digest, Vol 5, Issue 1598
- From: Brad O'Hearne <email@hidden>
- Date: Wed, 10 Sep 2008 11:00:29 -0700
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@hidden> wrote:
On 10-Sep-08, at 04:59 , email@hidden 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 (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden