A new Flexera Community experience is coming on November 18th, click here for more information.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Making the most out of Categories

We don’t make use of Categories very well in our App Portal. Our users only search for applications, never browse.

I’d like to set up intuitive categories but am at a loss at where to start. We have 1000+ applications.

We don’t have our App Portal integrated with FMNS, but saying that I was not blown away with the FNMS categorizations.

Has anyone managed to use the Categories effectively – or do your users just search for what they want?

(1) Solution

@Ralph_Crowley  Thanks for jumping in.  I'd love to see what input other customers have as well, so everyone out there, please join in.

In the meantime, I'll throw in a few random thoughts of my own:

  1. I hear from a lot of customers that their users just search instead of browsing.  There is absolutely nothing wrong with that if that's what users naturally do and it helps them quickly get what they need to get their work done.  Many people have become accustomed to that approach through daily life (online shopping, installing mobile device apps from one of the multiple app stores, etc.).
  2. There likely isn't a one-size-fits-all approach to categories.  What works for one organization may not work well for another organization.  People are unique in every facet, including how they logically process information.  While one user might be familiar with a product and look for it by publisher or product name, another user may just know that they need to open a particular file type.  Search can often be the most flexible way to solve that problem (see point #1).
  3. I've seen customers successfully use Flexera's pre-defined categorization from both Data Platform and from FNMS (similar but different categorization structures).  However, it may be necessary to use that as a starting point and make some slight changes that work for you and your users.  For example, the FNMS categorization has up to 3 levels and almost 200 categories.  That's a lot of information for a user to process, and you may find that going all the way to the leaf level of categories is unnecessary.  I've recently finished an implementation where we used the FNMS categorization, but we put a set of rules around it to limit the category structure to one level.  Here's what we did:
    1. Remove the top level category (always "Software", so not really helpful).  If a software title is assigned to the root "Software" category in FNMS, manually find a more appropriate category or put it in "Other".
    2. Use the second-level category for most software titles.  Some examples of second-level categories in FNMS are "Computer Game", "Content Authoring and Editing", "Development", "Educational or Reference", "Network Management", etc.  Most of these are pretty useful and would make sense to a lot of users browsing for software, without having to go down to the third-level category (more granular than necessary).  However, there are a couple second-level categories named "Business Function Specific" and "Industry Specific".  These are not generally helpful on their own.
    3. Use the third-level category for software titles where the second-level category name ends in "...Specific".  For example, instead of "Business Function Specific \ Label Making", you would simply use "Label Making", which is much more descriptive and helpful.  Depending on your situation, you might still choose to keep the second level as a parent category and use the third level as a subcategory, but in this case, we just rolled the third-level category up with the other second level categories.
    4. Use your best judgment.  You may find that some applications are categorized in a way that doesn't make sense to you or your users.  Or perhaps there is another category you feel is more suitable.  You don't have to use a particular category just because that's what the ARL says is right.  If you think it should go somewhere else, put it there.  If you aren't sure where something should go, stick it into an "Other" catch-all category.
  4. I recommend doing periodic user research studies.  Since your user population is always changing, the best way to categorize software may change along with it.  Every few months (or once  year - whatever works for you), run a report of all requests submitted in that period and randomly select a handful of users to participate in a user research study.  Give them some sample scenarios and ask them to locate and request the software they would need for such a scenario.  Watch what they do and ask them to describe their thought process aloud as they perform the tasks.  (Note: consider recording the session if they'll allow you to do so.)  Don't interrupt or help as they do it.  When finished, if they did something a different way than you expected (e.g. searched instead of browsing), ask them why?  If they had trouble completing a task, ask what you could do differently to make it easier for them?  Just make sure they know there are no wrong answers and you're just trying to learn from them to provide a better product to them and their peers.
Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".

View solution in original post

(6) Replies

Hello Nicola

As your account does purchase both App Portal and FNMS, therefore you should have a way to refer both side of 'content' at hands.

I am not 100% of sure your real challenge in your case though , but this is my guess

1. You want to have a quick way to match ARL's applications and find out what 'ARL's category' of those mapped one? then try 'rectify' the category in your App portal accordingly ?

2. Or you want to a bulk 'introduce' all the 'ARL Category' items into App Portal categories during 'new creation' ...then in future your App Portal will have a complete 'category list' from FNMS product ?

Regardless which one is your real question, this is indeed a good use and suggestion here , So forum is a good place for you to use and listen other customers' inputs.  

The key here is how you can quickly mapping the existing catalog in App Portal vs FNMS ARL here.  In FNMS ARL, all the applications are carefully classified into the following fields "ProductName/ Version/Edition/Publisher/ Classification (commercial or freeware etc)/ Category (Office tool or game etc )  . The table in FNMS you can utilize is  dbo.SoftwareTitleInfo table. I am sure you are able to find it useful.  It will fully depends on how your App Portal existing 1000 category naming convention is used, but it's feasible to do some mapping by excel or sql to give you some quick 'mapping' (certainly some manual/review is required for those not mapped between two products).

If the question is simply to introduce the ARL category list into App Portal. The list in ARL system you can quickly extract is via below sql query

select * from groupex where GroupExId Like '4%'

It's about 170 rows items that you can consider what to add in App Portal 

 

HTH

 

Cheers

Kevin

 

(Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".)

Hi Kevin,

Thanks for the reply.

I don’t really want to use the FNMS categories as:

  • Not all our Applications are identified in the ARLs (I have sent ARL Update requests but as you know these can take a long time)
  • Not all applications are categorised the way I would expect in the ARLs (for example, there are 11,000+ that are classified as ‘software’)

I was really just wondering if other organisations ever found a way to effectively set and use categories, and also, do their users even use them, or do they just search for Applications like mine seem to do.

Cheers,

Nicola

We use categories mostly for controlling access to groups of catalog items. Line of business apps are available to everyone, & core applications (which should be on every client) are mostly 'hidden' & only visible for our power users (Desktop Support techs). Other than that, we find most users do use global search to find the specific catalog item requested. Hope that helps

@Ralph_Crowley  Thanks for jumping in.  I'd love to see what input other customers have as well, so everyone out there, please join in.

In the meantime, I'll throw in a few random thoughts of my own:

  1. I hear from a lot of customers that their users just search instead of browsing.  There is absolutely nothing wrong with that if that's what users naturally do and it helps them quickly get what they need to get their work done.  Many people have become accustomed to that approach through daily life (online shopping, installing mobile device apps from one of the multiple app stores, etc.).
  2. There likely isn't a one-size-fits-all approach to categories.  What works for one organization may not work well for another organization.  People are unique in every facet, including how they logically process information.  While one user might be familiar with a product and look for it by publisher or product name, another user may just know that they need to open a particular file type.  Search can often be the most flexible way to solve that problem (see point #1).
  3. I've seen customers successfully use Flexera's pre-defined categorization from both Data Platform and from FNMS (similar but different categorization structures).  However, it may be necessary to use that as a starting point and make some slight changes that work for you and your users.  For example, the FNMS categorization has up to 3 levels and almost 200 categories.  That's a lot of information for a user to process, and you may find that going all the way to the leaf level of categories is unnecessary.  I've recently finished an implementation where we used the FNMS categorization, but we put a set of rules around it to limit the category structure to one level.  Here's what we did:
    1. Remove the top level category (always "Software", so not really helpful).  If a software title is assigned to the root "Software" category in FNMS, manually find a more appropriate category or put it in "Other".
    2. Use the second-level category for most software titles.  Some examples of second-level categories in FNMS are "Computer Game", "Content Authoring and Editing", "Development", "Educational or Reference", "Network Management", etc.  Most of these are pretty useful and would make sense to a lot of users browsing for software, without having to go down to the third-level category (more granular than necessary).  However, there are a couple second-level categories named "Business Function Specific" and "Industry Specific".  These are not generally helpful on their own.
    3. Use the third-level category for software titles where the second-level category name ends in "...Specific".  For example, instead of "Business Function Specific \ Label Making", you would simply use "Label Making", which is much more descriptive and helpful.  Depending on your situation, you might still choose to keep the second level as a parent category and use the third level as a subcategory, but in this case, we just rolled the third-level category up with the other second level categories.
    4. Use your best judgment.  You may find that some applications are categorized in a way that doesn't make sense to you or your users.  Or perhaps there is another category you feel is more suitable.  You don't have to use a particular category just because that's what the ARL says is right.  If you think it should go somewhere else, put it there.  If you aren't sure where something should go, stick it into an "Other" catch-all category.
  4. I recommend doing periodic user research studies.  Since your user population is always changing, the best way to categorize software may change along with it.  Every few months (or once  year - whatever works for you), run a report of all requests submitted in that period and randomly select a handful of users to participate in a user research study.  Give them some sample scenarios and ask them to locate and request the software they would need for such a scenario.  Watch what they do and ask them to describe their thought process aloud as they perform the tasks.  (Note: consider recording the session if they'll allow you to do so.)  Don't interrupt or help as they do it.  When finished, if they did something a different way than you expected (e.g. searched instead of browsing), ask them why?  If they had trouble completing a task, ask what you could do differently to make it easier for them?  Just make sure they know there are no wrong answers and you're just trying to learn from them to provide a better product to them and their peers.
Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".

Those are great thoughts for Random thoughts!!

I’m going to start to update our categories based around your point 3. I have already matched (in a spreadsheet) our App Portal items to the FNMS categorizations, I’ve used a cut down category list and added some other categories that are specific to our organisation.

If nothing else it will improve the look of our App Portal because the current categories we have defines are not great.

I like the idea of periodic user research studies, this is something else I will set up.

Thanks again,

Nic

Thanks for sharing that Ralph. Using 'Hidden' Categories is something we just started doing too, it's a good feature to use.

I imaging most users out there are comfortable with the search option, I know mine are. If they can't find what they are looking for,  they'll  request to onboard a new application.

I might try using the categories @jdempsey mentioned in his reply , MAYBE then some users might take a browse around the categories if they don't initially find what they are looking for in their search. They might find an alternate application which has similar functionality, instead of requesting to on-board another one.