Maintain Dock as new applications are installed

[khurram]

What standards are being followed for maintaining Dock while new apps are being added on the computer via Self Service. We found it important to add items (specially installed by Self Service) to Dock because after the user has installed the app they dont know that it has gone to Applications folder. We are currently using configuration profile to do that but that is not the proper solution when you dont know what apps will be installed on which computer.

[milesleacy]

If a Configuration Profile that adds "Application X" to the Dock is scoped to a Smart Computer Group of computers whith the criterion "Application title has Application X", that seems like the most appropriate and straightforward way to accomplish the goal.

As the JSS administrator, I know which applications I've published in Self Service; therefore I know which Configuration Profiles need to be created.

What issues are you encountering with this workflow?

The above is how I would add apps to a user's dock if I absolutely had to, but given the choice, I'd rather invest my effort in teaching users how Finder, Launchpad, Spotlight, and the Dock work than in managing their Docks for them.

[bpavlov]

@khurram We do not add items to the dock. The simple reason being is that this is not standard OS X behavior. If you go to the App Store, the app is put in /Applications and that's it. Might be visible from LaunchPad since it's all slowly and shiny, but that's the extent of it. I like to think of Self Service as our own App Store to some extent and therefore do not worry about such trivial things. The only thing we do as far as the dock is concerned is set a default on initial log in. After that, the end user can configure it how they want.

But if you wanted, I suppose you can make use of something like dockutil to add the item to the dock.

I personally wouldn't make use of a config profile for this. I look at config profiles as things that need to be always enforced and I'm not trying to force a set dock for everyone. For example a lab might be a perfect scenario for which to use a config profile to manage the dock.

[mm2270]

Just to put something else out there that jumps off of the comment from @bpavlov, one of the first changes I pushed for when I started at my current position some years ago, was to stop automatically pushing icons to the Dock from Self Service policies. My reasoning was that the Dock is a personal thing for most people. Some folks love to shove every possible app icon they can in their Dock, some like to keep it relatively slim - only keeping their most used apps in the Dock. Still others hate the Dock and like to rip everything out of it, save for Finder and Trash which they can't remove, and hide the Dock altogether. There are lots of variations between these of course.
As such, I don't like the idea of forcing icons into the Dock during Self Service installations. However, there is still the issue of discoverability for people new to the Mac who seem to think installed apps are in the Dock and if its not there, its not installed.

So what I came up with was a simple script that uses jamfHelper to ask them if they want the icon for the app just installed added to their Dock. The script actually checks first to see if the icon is in their Dock before making such an offer. If its not, it offers this in a dialog. If they click "Yes", it adds it to the Dock using dockutil, and in some cases will attempt to place it near other similar applications, like adding Firefox next to Safari. If they click "No", it skips adding it, leaving their Dock as is. In that way, the user is given the choice and they make the decision, not IT, but we can automate it for them if needed. The script uses parameters, so its one script that we can customize per policy to know which application icon to add to the Dock, and whether it should try to group the icon next to another one in the Dock if present.

We've been using this process now for almost 4 years, and its been a success. The script output sent back to the policy log lets us see if the client clicked Yes or No, or if the icon was already in their Dock (in "upgrade" situations), so we've been able to easily see that this choice is very individual. I'd say around 70% of clients click Yes, but a not insignificant number click No, which kind of proves my theory that everyone has different methods of how they like their Dock to be set up.
Its a little extra user interaction at the end of a SS policy, but in my opinion its well worth it to maintain a good end user experience.

[mpermann]

@mm2270 are the scripts you are using to offer the end user this option in Self Service policies available to look at?

[mm2270]

@mpermann No, but I can certainly post it here, or on my github page if there is interest in it. There's nothing proprietary in the script so that's doable.

[mpermann]

@mm2270 your GitHub page is fine. Thanks.

[mm2270]

@mpermann Just an FYI, I got around to posting the script I referenced above to my github page. You can find it here

[mpermann]

@mm2270 thanks for posting that. I appreciate it.

[donmontalvo]

@bpavlov wrote:

We do not add items to the dock. The simple reason being is that this is not standard OS X behavior. If you go to the App Store, the app is put in /Applications and that's it. Might be visible from LaunchPad since it's all slowly and shiny, but that's the extent of it. I like to think of Self Service as our own App Store to some extent and therefore do not worry about such trivial things. The only thing we do as far as the dock is concerned is set a default on initial log in. After that, the end user can configure it how they want.

@mm2270 wrote:

Just to put something else out there that jumps off of the comment from @bpavlov, one of the first changes I pushed for when I started at my current position some years ago, was to stop automatically pushing icons to the Dock from Self Service policies. My reasoning was that the Dock is a personal thing for most people.

Same here, we stopped adding icons to the Dock a few years ago, and we teach users to use LaunchPad or SpotLight. It was a hard habit to break, micromanaging the user's space, but glad to get away from it.

Less cycles wasted on something that at the end of the day doesn't really matter from a management perspective. Besides, not a fan of someone coming to my house and rearranging my furniture. :)

Don