Munki2 - Add clearer indication of already installed applications in Software view of MSC

[GoogleCodeExporter]

In the Software view in MSC it would be nice to have a clearer distinction of 
Applications that are installed vs apps that are available for install 
(optional_installs). As it is currently there is no indication an app is 
installed other than the "install" "remove" buttons (which are both the same 
length, same colour and same shape). 

Something like making "install" a different colour (blue?)

Original issue reported on code.google.com by bart.rea...@gmail.com on 4 Mar 2014 at 10:06

[GoogleCodeExporter]

suggest adding the following to base.css

div.msu-button-inner.not-installed {
    background: -webkit-gradient(linear, left top, left bottom, from( #367FD4), color-stop(0.50, #2255A0), color-stop(0.49, #2B68B6), to( #234F92));
}

div.msu-button-inner.not-installed:hover {
    background: -webkit-gradient(linear, left top, left bottom, from( #0067B8), color-stop(0.49, #00509A), color-stop(0.50, #003E85), to( #003777));
}

Original comment by bart.rea...@gmail.com on 4 Mar 2014 at 12:46

[GoogleCodeExporter]

"In the Software view in MSC it would be nice to have a clearer distinction of 
Applications that are installed vs apps that are available for install 
(optional_installs)."

Why would this be important? What problem or use case does it solve?

"As it is currently there is no indication an app is installed other than the 
"install" "remove" buttons (which are both the same length, same colour and 
same shape)." How about the line of text above the button that says "Installed" 
for items that are installed? That's an indication...

Compare also the Mac App Store app in this regard.

Early on I did experiment with changing the color of the button depending on 
the item status. I didn't like the look.

Original comment by gregnea...@mac.com on 4 Mar 2014 at 7:48

[GoogleCodeExporter]

I just feel the current installed status indicators tend to blend in. Even 
though there are indicators and you or I can differentiate them some clear 
at-a-glance differentiator needs to be present. A different icon, different 
badge, different button colour or shape. Something that is unique to an 
uninstalled application vs an already installed optional install. 

The apple App Store does show the same button shape and colour for installed vs 
purchase but then the App Store doesn't have the ability to remove apps and 
this is where I feel a distinction needs to be made. "Remove" is unique to MSC.

Original comment by bart.rea...@gmail.com on 4 Mar 2014 at 8:55

[GoogleCodeExporter]

It's still not clear what the user story is here.

I am a user of MSC.app. I'm looking for some new piece of software to install. 
Why is it important to quickly visually identify the ones that are already 
installed? If I want to find and install Adobe Photoshop CS6, I don't really 
care about the installation state of Google Earth...

Original comment by gregnea...@mac.com on 4 Mar 2014 at 9:04

[GoogleCodeExporter]

As an application advertising space it would make sense to clearly indicate 
what's already installed and what isn't. In our setup at least there are a lot 
of optional installs so while someone may open MSC to install a specific 
application, there may be additional applications they aren't aware aren't 
installed that they may want.

I've tried several colours on both the "install" button and "remove" button and 
agree it's touch to find something that works. The best I've managed to come up 
with is a flat shaded green for the "install" button but perhaps something like 
a trashcan or similar motif on the "remove" button.

Original comment by bart.rea...@gmail.com on 4 Mar 2014 at 10:26

[GoogleCodeExporter]

I don't currently plan to make any changes here. I like the way it looks and 
works. I have not yet seen a description of a actual end-user task that would 
make distinguishing installed/not-installed at a glance important.

Original comment by gregnea...@mac.com on 4 Mar 2014 at 10:31

[GoogleCodeExporter]

Fair enough. I guess it depends on how munki is to be implemented. In my 
environment we will be hosting our entire application catalog and installs 
managed via optional_installs on an individual machine basis using conditional 
items as well as a large collection of additional optional_installs available 
to everyone in a separate included manifest. There will be very few managed 
installs where the end user has no option to uninstall.

So, large list of applications, most of them optional_installs. For this 
reason, I'd like to distinguish, as an additional visual aid, installed vs 
not-installed as MSC differs in operation to the MAS in its ability to remove 
installed applications.

I've attached a mock up image of the color change to not-installed items.

This may be a use case outside the norm so in lieu of having this feature as 
standard can I request the ability to provide modified/additional CSS (hosted 
with the munki repo, not locally) to avoid running with a custom build. If this 
is already planned, then great.

Original comment by bart.rea...@gmail.com on 4 Mar 2014 at 11:57

Attachments:

• [Screen Shot 2014-03-05 at 10.36.37 AM.png](https://storage.googleapis.com/google-code-attachments/munki/issue-284/comment-7/Screen Shot 2014-03-05 at 10.36.37 AM.png)

[GoogleCodeExporter]

"So, large list of applications, most of them optional_installs."

Only optional installs are displayed in this view.

"For this reason, I'd like to distinguish, as an additional visual aid, 
installed vs not-installed as MSC differs in operation to the MAS in its 
ability to remove installed applications."

There's no reason there that I can understand.  You want to visually 
distinguish installed vs. not-installed so that the user might do exactly what 
with that information that they cannot do now?

"I've attached a mock up image of the color change to not-installed items."

There are other states. If the item listed is newer than the one currently 
installed, the button says "Update".  There are also states in which the button 
might say "Unavailable". Would these require other colors?

"This may be a use case outside the norm so in lieu of having this feature as 
standard can I request the ability to provide modified/additional CSS (hosted 
with the munki repo, not locally) to avoid running with a custom build. If this 
is already planned, then great."

Not currently planned. There's already too many moving parts with Cooca, 
Python, JavaScript, HTML and CSS. Not specifically _opposed_ to it, just not 
something on my top 100 things to work on...

Original comment by gregnea...@mac.com on 5 Mar 2014 at 12:05

[GoogleCodeExporter]

"There are other states. If the item listed is newer than the one currently 
installed, the button says "Update".  There are also states in which the button 
might say "Unavailable". Would these require other colors?"

Yes. Remove should be red.

"Not currently planned. There's already too many moving parts with Cooca, 
Python, JavaScript, HTML and CSS. Not specifically _opposed_ to it, just not 
something on my top 100 things to work on..."

I think the idea is valid, as users sometimes are not the most "aware" but it's 
not a show-stopper.

Original comment by eriknico...@gmail.com on 5 Mar 2014 at 12:10

[GoogleCodeExporter]

?"There are other states. If the item listed is newer than the one currently 
installed, the button says "Update".  There are also states in which the button 
might say "Unavailable". Would these require other colors?"

Yes. Remove should be red."

I tried that. Window ended up looking like a Christmas tree with Green Install 
and Red Remove buttons. Several early testers (and I) didn't like the look.

Still have yet to see a convincing reason to distinguish these with garish 
colors. So far it appears to be a matter of taste.

Original comment by gregnea...@mac.com on 5 Mar 2014 at 12:12

[GoogleCodeExporter]

"I tried that. Window ended up looking like a Christmas tree with Green Install 
and Red Remove buttons."

On that I agree. I also don't think changing the remove button to a colour is a 
good thing as more often than not, the software is going to be installed so 
filling the page with red maybe not a good thing.

If the "remove" was longer perhaps. Anything to distinguish it from the 
"install" button as they are currently both the same size, colour, font etc. 
which is why I'm also open to glyphs or other indicators other than grey 
buttons and grey text.

Not show stoppers, but knowing my users they are going to either hit the wrong 
button because they don't read or complain they can't find stuff because they 
don't look.

Original comment by bart.rea...@gmail.com on 5 Mar 2014 at 12:33

[GoogleCodeExporter]

While MAS doesn't have red, it does have a separate state/color for 
installations and currently installed items. MAS also requires the user to 
click twice to install any application. 

While this is a different issue, user may occasionally install an application 
incorrectly because it immediately begins to install. Maybe the true issue is 
MSC is showing all items by default. If it only showed installable items, this 
may reduce the user confusion Bart is worried about. I could see this being 
somewhat confusing for a user if there are 20 + items of mixed statuses.

Original comment by eriknico...@gmail.com on 5 Mar 2014 at 7:09

[GoogleCodeExporter]

"user may occasionally install an application incorrectly because it 
immediately begins to install"

For a very loose definition of "immediately". In actuality, they have several 
seconds (10 or more?) to click Cancel. Is this not what you are seeing?

I think when a user clicks a button labelled "Install" they have a reasonable 
expectation that it will cause the item to be installed. If they make a 
mistake, they have a few seconds to cancel, or in most cases, they can later 
click "Remove".

Original comment by gregnea...@mac.com on 5 Mar 2014 at 7:35

[GoogleCodeExporter]

I wasn't physically counting last night, but it didn't feel like 10 seconds. I 
was staging in a VM client on a SSD though. I think the "several seconds" 
depends more on size of package, WAN/LAN bandwidth and machine speed.

As far as what the user expects, a double click/tap makes more sense than a 
"click twice" to cancel, even if the button changes labels. I'm sure there is a 
reason MAS/AS require this. One could argue that user's could get confused in 
MSC due to this difference, but I feel I may be stretching the argument. 

Perhaps HIG is the answer (currently mixing recessed scope and push button), 
which I'm sure you're trying to follow as best as possible.

Original comment by eriknico...@gmail.com on 5 Mar 2014 at 11:05

[GoogleCodeExporter]

"I wasn't physically counting last night, but it didn't feel like 10 seconds. I 
was staging in a VM client on a SSD though. I think the "several seconds" 
depends more on size of package, WAN/LAN bandwidth and machine speed."

It's not a fixed time. It's the time it takes to do an updatecheck run. This 
time can vary.

"As far as what the user expects, a double click/tap makes more sense than a 
"click twice" to cancel, even if the button changes labels. I'm sure there is a 
reason MAS/AS require this"

Button first displays the price, or "Free".
You click it, and it changes to "Buy App" or "Install App".

What would be the two-stage equivalent for MSC.app? I couldn't think of one 
that wasn't more confusing.

Install App
Really Install App
?

" One could argue that user's could get confused in MSC due to this difference, 
but I feel I may be stretching the argument. 
Perhaps HIG is the answer (currently mixing recessed scope and push button), 
which I'm sure you're trying to follow as best as possible."

Ha. The App Store doesn't follow HIG -- it's a wrapper around a WebView (just 
like MSC.app)

Original comment by gregnea...@mac.com on 5 Mar 2014 at 11:15

[GoogleCodeExporter]

"What would be the two-stage equivalent for MSC.app? I couldn't think of one 
that wasn't more confusing.

Install App
Really Install App
?"

Yeah, I couldn't think of one either.
Install
Accept OR Proceed

I think the problem lies in this concept fundamentally not existing elsewhere.

How about this?

License Available
Install

This would tie into the seat feature you implemented last year. Kill two 
birds....

Original comment by eriknico...@gmail.com on 5 Mar 2014 at 11:41

[GoogleCodeExporter]

"How about this?

License Available
Install

This would tie into the seat feature you implemented last year. Kill two 
birds...."

But there would _still_ be a delay of some seconds or minutes until the actual 
install occurred. What should the button read during that phase?

Feel free to continue to think about this, but I plan no action anytime soon 
since there is no consensus. And we've wandered from the original issue anyway.

Original comment by gregnea...@mac.com on 5 Mar 2014 at 11:46

[GoogleCodeExporter]

Well for what it's worth, I gave a demo to our CTO and half a dozen other IT 
personnel today. The general consensus between all grey and a green "install" 
(similar to the pic i posted earlier but slightly different shade) was they 
liked the distinction between install and everything else vs having the grey 
install button. I didn't prompt for my preference. I populated my repo with ~15 
applications and installed roughly half in a random manner so it was a mix of 
green install buttons over the screen and it didn't look garish or christmas 
tree like, especially once the screen is filled with icons as MSC knows about 
them. 

At this point I have the changes to base.css  to colour the install button a 
non-offensive green and perform a build whenever there is a new release after a 
git pull and I'm happy to keep doing this.

I don't think a 2 click install would work as well and the "click->oops->click 
to cancel" has worked well enough for me so far in MSC. The issue for me has 
always been about the at-a-glance indication of what's installed and what isn't.

Original comment by bart.rea...@gmail.com on 6 Mar 2014 at 7:19

[GoogleCodeExporter]

We can reopen this (or open a new enhancement request) in the future. No plans 
to implant this at the current time.

Original comment by gregnea...@mac.com on 23 Mar 2014 at 3:00

• Changed state: WontFix