|Behind the Scenes|
Accessbility and Usability don't stop at the front door.
| 5:39 pm on Dec 12, 2006 (gmt 0)|
It took me a little bit to decide where I wanted to post these questions and after careful consideration, I decided that this topic is definitely an Accessibility and Usability issue.
You've got an online store that needs to be revamped from the ground up. You have 2,000+ unique products. Now it's time to start categorizing everything. How would you do it?
Here's where I'm at right now. Because the products can be listed under multiple categories, there is an added twist. I now have to figure out the best way to make the administration of these products user friendly for the administrators. But, how the heck can I do it efficiently and cost effectively?
How about this? I list all the products within "Manufacturer" categories. From there, I can then "cross pollenate" those products. I can assign them to an infinite number of categories.
I can see those categories in the administration interface. I can browse to them from a navigation tree at left that expands and collapses. And then, I can edit a product from within any category I may be in where it is assigned.
So, I have this global product record (within a manufactuer category) that is then shared amongst an infinite number of categories. Am I providing the best solution?
| 8:22 pm on Dec 12, 2006 (gmt 0)|
This is a fantastic topic--I sometimes have the cynical feeling that nobody ever thinks about this when they build web apps.
I don't have a lot of concrete advice for you, since it's probably impossible without knowing your administrators' preferred workflow(s) and a lot of other details, but I can think of a couple of things that web applications seldom do well:
- Provide Useful Access Points [google.com]
What you seem to be talking about are access points, and you're effectively building a library system, so think about accessing items in a library:
Remember the old-style library card catalogues? You could access the same records by subject (category), author (manufacturer), or title (product name). And if you happen to know the unique identifier (sku) of the item, you can just walk into the stacks and pick it up.
Budget permitting, it's a very good idea to provide several access points so that your admins can easily access sets of items to work with as easily as they can access individual items; sale on snow tires? Bring up the 'tires' category. Supplier out of stock? Sort by manufacturer. Product recall? Search by title. Pricing error? Find the sku.
If your budget will stand it, it's also smart to consider providing a means for users to combine subject/author and title when retrieving records; this allows for very precise searches even when one or more pieces of information is not known. For example, if you need the sku (call number) of an item, you could search by category, manufacturer and title; this should return a very short series of results.
If I were building a system like this from scratch, I would also try to improve on the UI--search boxes seem to be hard for many people to use, so you might consider another approach.
- Allow Multiple Item Editing
This is related to what I said about accessing sets of items above, and any time I have to deal with more than about 25 records, it's something I wind up wishing for.
Situation: Imagine your shop sells automotive parts, but that the owner decides to branch out into bicycle parts too. Now since bicycles and cars share many similarly-named components, every item in the database will need to be added to either the 'automotive' or 'bicycle' category. Obviously in an example like this, the developer can take care of it with a bit of sql, but I find that situations like this arise quite frequently, and it's very convenient if the admins can do this sort of work themselves without calling in the development team.
Obviously all of this is subject to budget and to the actual workflow inside the company in question, but these are the two things I most often find myself frustrated by/longing for in web apps of all descriptions...
| 2:11 pm on Dec 13, 2006 (gmt 0)|
|Provide Useful Access Points |
What you seem to be talking about are access points, and you're effectively building a library system, so think about accessing items in a library.
That's a great analogy bedlam. I like the term Access Points as that is exactly what I'm developing. I want the administrators to be able to access any product, from any category. I don't want them to have to click back or perform another function that is not needed.
Access Points, I like that. I've been referring to it as Cross Pollination and Category Association. ;)
| 10:38 pm on Dec 13, 2006 (gmt 0)|
pageoneresults, why not use the front end categorisation for the back end as well? I am thinking have refinement like you have on price comparison portals.
Take computers for example, you can compare by processor speed, RAM, brand, price, screen size etc...
Try to define what makes a product and find similarities that could be use as categories.
I guess it's the same as the access point bedlam mentioned.
| 2:23 pm on Dec 14, 2006 (gmt 0)|
|pageoneresults, why not use the front end categorisation for the back end as well? |
That was the original plan. But, after doing a further discovery of the products and how they could be classified, we're now going to do the exact opposite. Use the back end categorization for the front end as well. ;)
It is truly becoming a very user friendly structure. We're finalizing the product globalization right now and making a few adjustments here and there. I'm actually excited and looking forward to working with this new interface.
| 4:13 pm on Dec 21, 2006 (gmt 0)|
The structure you are describing is exactly what I am utilizing for numerous companies with 100,000+ unique SKUs (Stock Keeping Units; or unique items).
Master product record
Master item record (one to many [1:*] relationship between product and item)
Category record: any number of products may be assigned to any given category; any given product may be assigned to any number of categories
Category relationship record: defines parent-child relationships for category structure
When administering the products and their categories you can:
* categorize or recategorize any number of products at once (caveat: the products must all be assigned to the same category/ies when finished)
* edit/rename any category
* move/shift category order and position in the parent-child tree
* access any product via category tree (whichever branch you choose does not matter, as in the end you end up with a pointer to the master product record) for editing
* access multiple products in a spreadsheet view for bulk editing; view based on any given category (and/or subcategories) or as a result on a freetext search
Works quite well! I think you are definitely choosing the best possible solution.
| 3:05 pm on Dec 22, 2006 (gmt 0)|
|Access any product via category tree (whichever branch you choose does not matter, as in the end you end up with a pointer to the master product record) for editing |
That was the icing on the cake. Without that, it wouldn't have worked. :)
The category tree was also another nice added feature. We're using a collapsable menu system that makes locating a product quick and easy.
|Works quite well! I think you are definitely choosing the best possible solution. |
Thanks for confirming the solution.
Now comes the fun part, reentering all of the product data under the new system. Thousands and thousands of products. No, it can't be imported, the client is using a proprietary cart system that doesn't allow the exporting of data. :(