Do not display unavailable apps
S
Sheridan College
most of our support calls are for applications that are visible to users, but they are unavailable (grayed out) for one reason or another for example they are not on the domain. Is there a way to hide the unavailable apps from the user, depending on where they are coming from they see a different list if for example they connected from Azure virtual desktop, or a different list if they connected from laptop, but I just need a way to hide the grayed out apps.
maybe have an option so that the college can decide how to present the apps to the user.
V
Vicki Marriner
I initially liked the idea of this, but it has recently been causing us support issues. We have a student desktop icon on AppsAnywhere for MacOS users to connect to, to run AppsAnywhere on a Windows VM. Previously this was one of the few icons visible to them, with the others being some downloads for Mac installers and web pages, and it was clear to launch the student desktop. Now they see all apps, even those only available to Windows devices (over 100 apps as unavailable), so we have been getting reports that they think their Mac OS versions aren't compatible with all the unavailable apps that are showing, and it is hard to pick out the student desktop icon amongst them. I guess the easy solution on the face of it is if they search for the student desktop icon, but a large number of people dont appear to be doing this. I think it was a better experience previously where the unavailable apps weren't so visible for MacOS provisioned apps in our case, and they could just see what was available to them.
Lewis, Creative & UI-UX Lead @ AppsAnywhere
Vicki Marriner: Hi Vicki, thanks for outlining your use case. The reason this was changed in 2.12 was for the opposite scenario really - to avoid apps that students use in a lab, for example, disappearing completely when they used their own device without any explanation (since it seemed that not everybody noticed the unavailable option at all). It sounds like there might be use cases where you're unable to set things up as you'd like to make those apps available to all users, so hopefully we can look into what options are available to us.
I think it depends on how things are set up for you and why - I understand that you have the single desktop within which Mac users search for their apps as a method to avoid having to maintain the same delivery method on every one of those apps essentially - is that correct?
T
Tom Fish
We are using 3.1 and when using the Locally installed delivery method, applications that are not locally installed get the message
We couldn't determine why this application is unavailable.
If an applications delivery method is locally installed, if the client recognises that the path is not available via the launch exe, Directories, Uninstaller key do not exist on the device, then an output that application does not appear to be locally installed would be beneficial.
A
Allan Fishburn
We've noticed on AA 3.1 that if you deploy something with just a locally installed delivery method, and that app isn't installed on a PC, you get an unavailable app with the message “We couldn't determine why this application is unavailable”. This will cause confusion with the students, and in this scenario there should be a message that explains to students that the software isn't installed.
I think in general having unavailable apps showing is a good thing - as long as the description of why they're unavailable is clear. It would be good if you could toggle the showing of unavailable apps so each institution could take whichever path they prefer.
J
Jim Hobbs
Unavailable could be shuffled to the bottom as an expandable list with better descriptions on each to describe why they are unavailable. Specifying if no delivery method is available for this platform or requirements not met.
Lewis, Creative & UI-UX Lead @ AppsAnywhere
Jim Hobbs: Hi Jim, rearranging unavailable apps could be an option. In 2.11 and earlier, unavailable apps were their own filter. The feedback we got there was that when people did a search, unavailable apps didn't appear (because they were in their own section), and users thought the apps just disappeared altogether.
We wanted to make it so that you could always see that an app was just unavailable and not gone completely, and combined with the descriptions about why an app is unavailable from 2.12 onwards in the more info screen (which does include things like requirements, OS, restrictions) we believe that it's more clear for end users. There are some scenarios where we don't yet have all the facts about why an app is unavailble in the portal itself, but it's on our list to narrow that gap.
Alexandre Cop
Currently using 2.11 - It's really hard for an end user to understand why the application is not available
Lewis, Creative & UI-UX Lead @ AppsAnywhere
Alexandre Cop: Hi Alexandre. This is the reason we added a new mechanism for 2.12 that explains in simple terms why an app isn't available, and we hope to be able to expand that to more scenarios than ever before in a future version to cover as many as possible.
Alexandre Cop
Lewis, Creative & UI-UX Lead @ AppsAnywhere: now on 3.1 - It has improved (although like Jim says unavailables could shuffle to the bottom), but I noticed that the explanation does not handle when a user/device is not a member of an AD group
Lewis, Creative & UI-UX Lead @ AppsAnywhere
Alexandre Cop: Hi Alexandre. Great to hear you've upgraded and I hope you're enjoying it. Moving unavailable apps to the bottom could be tricky - as of course it depends on what you're looking at. For example, when you press show more in the search, or load more in the grid view, apps would have to shuffle around to keep unavailable at the bottom. Equally, when you validate and apps become available, everything would shuffle around again. We no longer load absolutely every app up front, which speeds things up, but also means the portal doesn't know whether there are any more unavailable apps to come.
Regarding the unavailable message - we do have an item in the backlog to expand on the scenarios the new notice can handle (currently it only covers the same information you used to see in More Info in 2.11, but in a more digestible format). For clarity, do you mean the restriction you can add to a delivery method to further select AD groups beyond provisions?
Alexandre Cop
Lewis, Creative & UI-UX Lead @ AppsAnywhere: Yes, the "Permitted directory mappings" bit in the DM Restrictions