Need Help Planning Architecture for Categorization Connundrum

Question

Hi Folks,

I have more of a "what-would-you-do" question than an actual coding question. It relates to a project I am currently working on. In this project, we are tasked with combining several marketplace APIs into one interface. Each API has its own unique way of categorizing products. The top-level parent categories for all the APIs we are looking at are more-or-less the same with some variations. But, the subcategories are wildly different.

For example, one API requires long bread-crumb trails to select a category, such as: Sports > Ball Sports > New England > Football > Active Teams > Patriots > Memorabilia. While another API has two-level categorization: Sports > Patriots Memorabilia. In many cases, there are sub-categories that don't relate whatsoever to the subcategories of other APIs.

So, the question is - what is the best approach to take when designing the interface? We are currently wrestling between two possibilities:

1) Design a custom category UI on the client and then build logic into the server that is able to sort through the needs of the various APIs based on user-selected choices.

2) Create the UI in such a way that the user has to walk through the necessary steps for each individual API. Depending on user settings, this means that he may need to fill out API - specific information 5,6,10, or more times.

While I am told that option number one is a real programming nightmare (the example I am given is changing API data fields) I feel strongly that option number two will piss off customers.

Any ideas out there??

Answer 1

You have to provide to your clients a consistent not changing interface.

I would like to see an example of the two different approaches you have in mind.

API.find( PRODUCT, CATEGORIES_LIST )

Answer 2

Number One isn't that bad of a nightmare. Your users' experience is the number one priority; never forget that. If the user has an easier time navigating a shorter route, then give them that opportunity. Also, I would wrap the API with some abstraction so my code doesn't know about the API at all and only knows about the abstraction layer. This way I can change APIs and leave most of my code alone, only changing the abstraction layer.

Use a session to pass data from page to page and a factory to create the page's state on entry based on the session data; this will strengthen the context between page, state, and user data.

Keep first level objects (the ones the page directly talks to) in context to the page; this will help when diagnosing problems.

Most importantly, create a series of tests for your abstraction layer that test every object, function, and input output pair to make sure your application is rock solid.

Answer 3

This a very hard problem. If you search for "ontology product classification" you'll find many research papers and discussions on the topic. If one was simply a more detailed version of the other it would be quite feasible, but your description implies that isn't the case, and thus you'll need to construct your own classification scheme and map the others onto it.

Do you have a common key (UPC code? or other) that will allow you to verify your mapping between the different product categories? If so, you might be able to construct your own categorization scheme and then map the others onto it with some degree of success.

Clearly the first option is the best for the consumer but it could be very hard and very time consuming to construct such a mapping and it will need constant updates.

One approach would be to construct a simpler hierarchy than any of the ones provided. A simpler hierarchy will make the [mostly manual] effort of mapping categories into your hierarchy much easier as most will simply be inclusions. This might make the user experience worse but if you add great search capabilities and great "related products" / "people who bought this also bought this" tools around the product browsing experience you can probably make up for the lack of hierarchy.