Related
On a D7 site I have a list of items displayed in a view.
The view is filtered by several different taxonomy vocabularies, each displayed as an exposed filter
ex:
Culture
Medium
Origin
Artist
My problem is, when you select, say, the drop-down for Culture, and choose a tag, say Yemenite, the view is filtered for items tagged with Yemenite.
But if I then click the drop-down for Medium, and choose a tag, say Metalwork, the view is filtered to show only items tagged with both Yemenite and Metalwork.
This is far too specific, but I can't find a way to make the filters operate independently where when I choose Medium, the filter for Culture is reset, and only Metalwork is shown. Filter groups and And/Or specifiers only create long chains of qualifiers rather than resetting and re-filtering.
I'm sure that this can be done using jQuery, but I'm on a tight schedule, and my experience overriding select lists with jQuery, and dealing with the cross-browser issues created has been pretty negative. I could also create an elaborate tag hierarchy and display the whole thing as a single filter, but that clutter really isn't viable, it's also problematic on mobile.
If anyone has any thoughts or pointers I would appreciate the help.
In the View you can change the behaviour of the exposed filter. In the list of exposed filters there's a tab with "Add" / "AND/OR, Rearrange". With the "AND/OR" option you can change the inclusive behaviour and set it to 'or'.
I have 3 level menus and i need to display each sub menu in diferrent modules. ie,
This is a 3 level menu, i need to display main menu in MODULE_ONE, and second level in MODULE_TWO and third level in MODULE_THREE position correspondingly, with out the tree structure . The modules three modules are in different position. How can i implement this in joomla 2.5. I have check and been able to display on second level but not possible to display 3rd level. please reply if there is a
thank you.
You can display 3 levels in 3 modules from the same menu, of course the second level's content will be determined by the first level selection; this will apply also to the third level.
However, please note that mod_menu used to have inadequate cache support, so by all means DO DISABLE the cache on the modules, else they won't work or will work funny (not showing the current page highlighted... changing the second menu "20" when you click on the first menu "3" ...)
Try the Splitmenu configuration of RocketTheme's RokNavMenu
Here's a discussion on how to accomplish that.
I will display a grid of a view model class M {string A, int B, float C, int D, .....}:
Render the number in red if it's negative.
Highlight the background of the cell if A is in 'xxx', 'zzz' and B = 0 or D > 200...
Set the background of the row to grey if E > 100 and F < 0....
Are these considered business logic? Where to put these logic if they are? For (3), I guess a new read-only property can be created in in the view model? But it make the M not POJO/POCO any more? I read that the business logic should be in domain object. Is the domain object implemented using POJO/POCO?
Is there any code sample shows how the business logic is stored in domain objects?
There are several ways to achieve what you are trying to do. You mention the term 'View-Model' a few times in your description, which makes me think you are trying to use the design pattern 'MVVM' (Model-View-ViewModel), which is popular when using WPF or Silverlight technology due to things like it's support for databinding against the view, but can be extended to other technologies too.
In MVVM, the tiers are split into the Model, the View-Model and the View.
The Model is essentially your domain, and is used only for Domain specific modelling. Your applications entities should live here, but there should be no calculations, or manipulation of the domain entities. eg. If it was a cycling domain, your 'Bike' and 'Rider' classes should live here, but there should be no code relating to calculating the race winners, or what colour to display the winner in your application GUI.
The View-Model is where you prepare your domain entities to be presented into your View (User interface). You pretty much achieve this by wrapping your domain entities into new classes, that take the domain object in the constructor, but then expose, or translate the existing properties into the ones you want to be displayed in the View. In the cycling analogy your Bike object might have Make, Model, Cost, RRP, TimeBuilt properties, so in the view model I would expose the Make, Model properties, but then translate the Cost and RRP along with margin to come up with the retail price (as seen on the front end).
The View, as you might have guessed is where this information is displayed. This might be a desktop, mobile or web front end - it doesn't really matter. This is also where any rendering of the UI should be achieved. If I wanted to highlight great deals to my customers, and colour any Bikes with very good retail prices in green - I would do it here.
So, when relating to your example, formatting how the object is displayed should be achieved in the View. Even if your not using MVVM, you can achieve very similar results by extending your domain objects into Wrapper classes to be deployed and manipulated. Your rules such as
Highlight the background of the cell if A is in 'xxx', 'zzz' and B = 0 or D > 200
can be modeled in a boolean on your view model class, giving you the effect you need, without polluting your domain objects with non-specific code.
Regardless of architectural choice, (MVC, MVP, MVVM etc) these are good guidelines to develop by, as they deploy separation of concerns between the layers of your application.
You could store the output of all your 3 calculations as properties on you object, then pass the calculated object to your view.
For example on point 1 render the number if it is negative. this color red could be passed to the view. the actual calculation that determines the color to be red could happen in your biz logic layer.
Please let me know if this helps.
The term "view model" is wrong. View and Model are two separate things, each dealing with a distinct/separate concern of the application: model encapsulating business logic, view handling presentation/display. In simple terms, model is your domain object.
What you have shown in your example, is presentation-related. It belongs to view, not to model.
I want to provide my users with an 'advanced' search engine.
I basically have a lot of search criteria to chose from :
some are very simple/common and will be largely use (ie time period, item id)
some are a bit less mainstream
and some won't be used a lot, but I still want to provide them
Overall, I have around 30+ criteria to chose from
The result is a dataset which I display in a grid.
I've search for inspiration on internet, and even google doesn't seem to have a nice solution for advanced search.
I've designed this kind of tools in the past, and I wasn't really pleased by the result, although the user were eventually able to use it quite effectively.
Do you think the search panel should be visible all the time (ie displayed on top of my result grid) or available in a separate form (which would let me use more place for all the controls)
Do you think it's better to display all the search criteria, or to let the user click on 'advanced' if he wants to see/use more criteria
How would you organize the criteria? by usage frequency, or rather by area (ie. criteria related to user, to location, to time, etc.)
Where should I put the 'Search' button? next to the more common search controls, or at the bottom, or both?
And more generally, do you have tips you want to share on how to design a nice search UI ?
What kind of functionalities do you usually miss in this kind of 'advanced' search engines?
Not an expert on UI, but I have seen a lot of bad UI.
KISS is a good start.
Make it intuitive.
Keep the search both at the top and at the bottom. I'd be loathe to use something that forces me to move up the page to type (see Flex documentation, their pagination control is only at the top -- a miserable pain you know where).
Organization of criteria should be two-fold:
basic operators (20%) which 80% will use up-front
dynamically edit the set of criteria available at any time.
Get the users started with least ramp-up time and allow them to add/remove criteria on a as needed basis. The idea is to make him use something he needs and not clutter his thought or workflow with the brilliance of your feature set.
As others have mentioned and is the trend nowadays with UI in general, use controls that are hidden until and unless the user explicitly wants advanced/fine-tuning (on-demand UI).
A good rule of thumb is to have a maximum of 5-7 features on a page.
It'd be great if you can arrange the criteria in such a way so as to make a story out of it i.e. the user can read his query and your operators make some meaning out of it.
I'm a big fan of little text and easy to comprehend icons but such a setup depends on your installation environment. Can your grandkid use that mighty workhorse?
Good design also necessiates that you make your UI accessible. That's a tough nut to crack and I have absolutely no idea how you'd do that.
Best of luck!
I tend to like the "list of rules" approach. You know the one:
Find items that match [ All |v] of these conditions:
[Name |v] [Contains |v] [_____________] (-) (+)
[Start date |v] [Is before |v] [_____________] (+)
(Cancel) (Search)
This keeps the dialog from getting too cluttered but still gives users all the options they might need.
But that assumes you need things to be that advanced! You might find that an intelligently-designed keyword list approach will work fine.
Keep the advanced controls hidden by default. Your search input and action button should always be visible and given prominence, regardless of whether or not your advanced controls are visible. Make sure that showing/hiding the advanced controls does not change the location of either the primary input or button - those need to remain static so the user's spatial memory is not affected.
As for the advanced controls, without knowing exactly what type of data you need to show, I can only give an overview of potential organization methods. Personally, I like LATCH:
Location
Alphabet
Time (timeline or chronology - think of a history museum)
Category (think department stores)
Heirarchy (biggest to smallest, lightest to darkest, etc.
Depending on your controls, one of those will make the most sense. Organize accordingly. If you can use a slider or range input (for example, 'lightest', 'lighter', etc.) rather than a list of checkboxes/radios, this is preferable as it reduces the number of visual elements on the page.
Forget about the "plus/minus 7" rule - that has been taken completely out of context by folks who did not actually read the study. In short - it's only applicable to the human's response to external stimuli, not options displayed on a screen. This isn't saying you should go overboard, but even if you have a lot of options, you can visually tweak them. Clutter is a failure of design - not information.
Remember to use plenty of whitespace and <label> elements to give each option a good-sized click target. This is especially important when dealing with checkboxes or radios.
Make sure that when the results are returned, there is a clear title (<h2> or <h3> usually suffices) re-stating the user's query, and how many results were returned. Don't forget about a 0 results page! Offer some advice on broadening the query, if possible.
Just a general advice: keep it simple. To much choice confuses the user and increases the chance a certain piece of functionality is not used.
Try different prototypes on users to findout which options are valuable and which are not.
1) Do you think the search panel should be visible on top of my result grid?
A simple search panel like Google’s basic search may be on the Results page since it’s compact. This allows the user to re-try the search with different criteria without wasting time going to a new page or window. Advanced search is much more cluttering so there’s a more important tradeoff between easy access to the results (in a smaller pane) and easy access to re-search, so you need to appraise the frequency users re-searching versus the work they do with the results. For example, if re-search happens 50% of the time, but including an Advanced Search panel in the Results page requires additional scrolling 75% of the time, your users are better off without an Advanced Search panel on the Results. As a general rule, Advanced Search should not be on the Results page unless the task is really cut-and-try exploration of the data.
Another issue with the Search panel at the top of the results is what to do if the results do not correspond to the criteria (e.g., if the user changes a criterion after the results are shown but before clicking Search again). With Advanced Search it is much easier for users to forget or miss whether they changed a criterion or not and then be confused about what criteria is in effect for the results. Putting Advanced Search on a separate page prevents this, although there are other ways to avoid this problem if Advanced Search is on the Results page (e.g., using instant-apply “faceted” search).
In any case, the Results page should display the criteria used in making the search.
2) Do you think it's better to let the user click on 'advanced' for more criteria?
For most database apps, users of a particular group (e.g., job position) have 2 to 5 specific sets of search criteria that get them through the vast majority of their work, (e.g., search for orders made between two user-supplied dates), sometimes including criteria that even have specific criterion values (e.g., search for all orders with a pending status). In this situation, users will be fastest and least likely to be confused if you have an Advanced button for ad hoc searching, while the default search has controls tailored for these specific searches. Default to Advanced Search only if your users will primarily be conducting exploratory ad hoc searches.
3) How would you organize the criteria?
If there are certain criteria that are used especially often, then they’re handled through Basic Search as described for 2, so there’s little advantage to sorting criteria in Advanced Search by frequency. It just makes it hard for users to find the criterion they’re looking for. Generally you can rely on users having a specific named field in mind, so sort the criterion alphabetically, or, if users are familiar with the Results Page and its fields are laid out in a manner consistent with how the users think, use the same order as used for the Results columns.
4) Where should I put the 'Search' button?
The Search Button ideally should always be visible. The best solution is to have all the criteria on a scrollable pane with the button outside the pane. Putting the button at the top and bottom is a common but kludgey alternative. I wouldn’t put it by the common criteria because if your users have gone from Basic to Advanced Search, they’re probably not using common criteria. Consider no Search Button if you can keep response time under 500 ms, instead providing instant-apply like seen in Vista.
5) How to design a nice search UI?
For field-based multi-criteria Search, there are two basic designs:
a. A form of all fields with a place to enter criterion values for each field. The problem with this is fields with set values can scroll out of view and users may have forgotten they’ve set a value. Thus you want to keep this as compact as possible. See the chapter Improving Data Retrieval in Alan Cooper’s About Face 2.0 for one approach. You can also provide a summary string of the selected criteria near the Search buttons which the user can check. Clicking each criteria in the string can even jump the user to the criteria for changing it.
b. The user selects from a list of fields those to be used in the criteria, then sets the values for the criteria in consolidated location. The main challenge here is to minimize the number of “overhead” clicks to select a field. Ideally, the list of fields are always available and one click selects the field, puts it in the consolidated location, and places the cursor in the value control, something like shown in http://www.zuschlogin.com/content/blogimages/37/FindAdvanced.gif, only for Search rather than Find. (By arbitrary convention “Find” is very different than “Search” for users; Find highlights things within the current page matching a given criteria while Search retrieves things matching a given criteria)
Both of these designs link the criterion for each field by logical ANDs and are limited in the joins among the underlying database tables, but that is likely satisfy nearly all your users. If the tasks require more complicated joins and Boolean combinations, look into graphical querying designs (e.g., Badre AN, Catarci T, Massari A, & Santucci G 1996. Comparative ease of use of a diagrammatic vs. An iconic query language. In J Kennedy & P Barclay (Eds) Interfaces to Databases (IDS-3): Proceedings of the 3rd International Workshop on Interfaces to Databases, Napier University, Edinburgh, 8-10 July) and Query by Example designs.
The default design pattern which I use is Filter Table. That covers maybe 90% of the use cases. For more complex searches, I would need more specific information on the goals and use cases of the users, so that it would be possible to design a more optimal solution for those situations.
Simple is good. I'd recommend an iterative approach where you slowly build functionality after doing user acceptance testing and watching the logs to see which features that they use (or don't use). The only way you'll know what to improve is to watch your users.
Try to keep the interface as simple as possible. Most users will only need a text window and a search button. The remaining options can be put inside of an advanced search option.
This setup is friendlier for new users, as well as helping to conserve resources by saving the more expensive advanced searches for people who actually need them.
my thoughts:
-Only show advanced criteria when it is desired. Search is a great thing when it is made as simple as possible to the people trying to search.
-If there is some very large set of search criteria for advanced searches: do not clutter the results with it. Make it very easy and obvious for a user to go back and modify the criteria, but don't try to waste space on the results by giving them their criteria again right off the bat.
-Organization of criteria is hard to say without knowing it all. but as others have/will say: make it simple! You might not need to show it all at once: let me expand areas if i want more, hide stuff i don't want to use. and then put a search button at the bottom of it. But again, I won't want to scroll through a page of random criteria just to find this button.
There should be a search text box as a part of the mast head on every page of the site.
I prefer that the button be labeled "find" instead of "search" because benefits are always more compelling than features.
What should be sophisticated is your search algorithm and not the GUI.
Please find my answers(in normal text) against each of the questions(in italics) asked.
"1) Do you think the search panel should be visible all the time (ie displayed on top of my result grid) or available in a separate form (which would let me use more place for all the controls)"
Display on top of result grid as this leaves extra horizontal space to display search results and thereby to display more columns of search data without scrolling horizontally.
"2) Do you think it's better to display all the search criteria, or to let the user click on 'advanced' if he wants to see/use more criteria"
Display all available criteria but in a tabbed fashion. i.e. categorize input search fields into categories and have a tab for each category.
"3) How would you organize the criteria? by usage frequency, or rather by area (ie. criteria related to user, to location, to time, etc.)"
Organize 'by area' because different people like using different criteria.
Each criteria would have tab of it's own. But organize the tabs in the order of 'more popular' to 'less popular' as you think. In your case tabs may be 'By Name'(containing fields first name, middle name, last name, mother maiden name, nick name, father's name etc), 'By Location' (place name, county name, district name, state name, country name etc)
and so on until the advanced tab(where you'd put least used fields).
"4) Where should I put the 'Search' button? next to the more common search controls, or at the bottom, or both?"
Put the input fields of search as discussed above in a tabbed fashion categorizing them based on 'type of field'(I'll refer to this area as search grid). Then put action buttons such as 'Search', 'Clear/Reset' just below the search grid aligning to the center(I'll refer to this area as button grid).Then put the search result pane below the button grid as more horizontal area is available for display so that maximum columns can be displayed at once.
Take a look at quince, the infragistics ui patterns site: http://quince.infragistics.com.
Personally, I'd look at using a filterable grid, like the xtragrid from DevExpress: http://www.devexpress.com/Products/NET/Controls/WinForms/Grid/datafiltering.xml
coupled with a search bar above it to initially populate the grid.
Don't think this has been mentioned yet but dont forget that you will also need to initiate the search when the user presses enter in any of the search fields. Probably aware of this already, but worth mentioning anyway.
I have a collection of items that the user needs to group/categorize in several ways. For the sake of an example, let's say it's a collection of cars and the user wants to categorize them in the following ways:
Color (red, silver, blue, black, etc.)
Body shape (hatch, sedan, coupe, stationwagon, etc.)
Seats (2, 4, 5, 6, etc.)
etc.
Have you ever come across a particularly elegant way of doing this that allows the user full freedom to define their own categories and values?
Obviously, there will many be trade-offs to make in any design. For example, a learnable design might not be efficient, and vice versa. Or some designs may be more demanding of real estate than others. And some will take significantly longer to develop than others.
Regardless, if you've seen -- or designed -- a good pattern for this, I'd be interested to hear about it. If you have screenshots, all the better.
Attempt at clarification: tags are indeed a great way of categorizing things, but in all implmentations I've seen, there's only ever one level of tagging. The user doesn't generally get to define a category/property and the item's value in that category. To use the example above and StackOverflow's tagging, you'd tag a car as "blue", "sedan", "4", and so on. StackOverflow would have no inherent knowledge that an item couldn't be tagged as both "sedan" and "coupe".
The interface I'm thinking of would need to know that kind of thing, so the user-defined attributes suggestion is more along the lines of what I'm thinking. I'm just keen to find a concrete example of how that kind of system could be elegantly implemented (in a desktop app, if that makes a difference).
Is that any clearer? If not, leave a comment and I'll try to clarify again. :)
It sounds like you have two tasks: Task 1 Categorize Objects, where for a series of objects, the user assigns each a category (value) on each of multiple dimensions (attributes). Task 2: Create and Modify Dimension and Categories.
Outside of data modelers, object-oriented programmers, and database designers, the idea of dimensions and categories is a very hard concept to grasp. You should be prepared for users not understanding the difference between categories and dimensions. However, users generally will understand tables, where each column is a dimension (that comprises several categories) and each row is an object. As much as possible, work with tables.
The first key question is to figure out through user research is the degree Task 1 and 2 are integrated or separate.
If the tasks are integrated, with users often switching fluidly from one to the other without much thought, then one UI design is to have a objects-by-dimension table, but provide a blank column (or an “Insert” button) to allow the user to add a dimension. The column header has the dimension name, which the user can edit. Under the header is a space listing the categories of that dimension. Each category name is editable and there is a blank line (or the Insert button) to add a new category. Below that are the objects to categorize, each with a dropdown list in each column for dimension.
In usability testing, watch out for users trying to set an object’s category by clicking on a category in the category list, rather than selecting from the dropdown list. Make the category list appear visually separate to prevent this.
You may want a button to hide/show the category lists, as this can take a lot of space (even when using scrollbars). Even if Task 1 and 2 are tightly integrated, I think you’ll find users may want to get the category lists out of the way sometimes.
If you find that Task 1 and 2 are separate, rarely being done together (e.g., users typically set up their dimensions then categorize a bunch of objects), then you’re better off with a separate window (or page) for each task, although it should be easy to navigate back and forth between them. For example, while users may typically set up their dimensions beforehand then rarely modify them, sometimes a user will realized one needs a new category for a dimension while categorizing an unusual object, so you provide a “Add category” menu item that takes the user to the Manage Categories window, with a new category inserted for the current dimension awaiting the user to provide a name.
The window for Task 1 is the same as before: table of objects with a column of dropdown lists for each dimension, but exclude the category lists, the editing of the dimension names, and the capacity to add a new dimension. This is most efficient if the user needs to scan for objects needing categorizing or re-categorizing, or if typically the user needs to compare one object against some others (e.g., to decide how to categorize the object). However, if the user’s task is truly limited to just categorizing an object one at a time based on outside information (e.g., transcribing information from paper), then consider a form rather than a table, showing an array of list boxes, one for each attribute. With a single click of each list box to set each category, this is faster than using dropdown lists.
The window for Task 2 could be like the header portion for task one. It is consistent with the table used for Task 1 and allows users to see categories for multiple dimensions at once, helping them figure out the best categorization scheme (e.g., help them find where essentially the same category appears in two different dimensions). If space is a problem, however, then consider a list of dimensions each showing a list of categories in a master-detail relation.
The ultimate in user power and flexibility for Task 2 is a tree-like control. The root level of the tree comprises dimensions and the next step in the hierarchy comprises the categories within each dimension. The main advantage is that it supports dimensions being dependent on categories. For example, one may have a Vehicle Type dimension that includes categories like Car, Boat, Plane, etc. For the Car category, one may then have a Body Type dimension with categories that only apply to that category (Coupe, Hatchback, etc.). Dependent dimensions are represented in the tree by branches off a category. The result is the tree alternates between dimensions and categories with each level in.
It’s important to visually distinguish the categories from the dimensions, perhaps by different icons, and maybe different font as well –something to tell users that alternating steps in the hierarchy are qualitatively different (e.g., if you create a Dimension, then you should create at least two categories). Even then, provide a means of easy recovery if users confuse dimensions with categories (e.g., allow them to move a bunch of “dimensions” to under another dimension, converting the former into categories).
I want to emphasize again the difficulty people have with abstractions like dimensions and categories. Even when they do understand it, people generally have great difficulty creating decent dimensions and categories on their own. There are complicated interactions that can result that you need to think through (e.g., what happens to object categorization when a category is moved to a new dimension?). If you are expecting each user to truly create their own novel dimensions, then you may want to seriously re-think your whole approach. It is an inherently complicated task.
User do much better if there’s already a relevant multi-dimensional scheme in the culture, organization, or domain (such as we have for cars). Of course, if there already is a scheme, then you can research it and install it as a default set of dimensions in your product. Task 2 only needs to be supported to allow expert users to fine-tune it.
You could use tags: Have the user tag each image, then show a set of image thumbnails sorted by tags.
Maybe more advanced than tags would be a set of user-defined attributes. For example, instead of tagging a picture with "red", tag it with an attribute "color=red".
I'd suggest a tagging system similar to the one here on stackoverflow. Allow them to tag the images, then view by tag, or combination of tabs. When viewing the page, show thumbnails of the images and the tags for that image below it.
Edit: Based on your clarifications you could have types of tags. When the user defines their own tag, they would need to specify which type it derivies from. With that in mind, you would need limit tags to only one of that type.
TagType { Color, Seats, BodyType, Seats }
TabSubType { Color-Red, Color-Blue, Color-Green, Seats-2, Seats-4, ... }
When a user wants to add tag an image give them a drop down with the TagType. Below that give then another drop down with the TabSubTypes. Give them an option to "Define New" which will cause a textbox to appear where they can type in a new type.
I'd also add these options to the context menu so users can view the tags in a tree style menu.
You could also grab the keypress even when an image is focused, look up the TagType and TagSubType name and present a menu of options to choose from. If no matches are found, offer a "Click to add new tag" option.
Faceted Classification is a way to categorize things that doesn't get the attention it deserves. It allows you to define mutually exclusive categories and provide a value for each content item for each category. For example, you could classify wines by region, varietal, vintage and price, and a user would conduct their search by picking one or more values in one or more categories. For example, “French or Italian reds under $40”. Assuming you have the category data at hand, this is often the most powerful classification and search technique available, better than trying to fit everything into a single hierarchy or relying on tags.
To implement this on the backend, make tables for each category and fill them with the distinct values. Then make a table what has a foreign key to each category table, together with a field that contains the content. This is similar to a “fact” table in dimensional database design.
To get an idea how this can works in the UI, take a look at Facetmap. I can’t vouch for their product because I haven’t used it, but I’ve implemented something similar for my own applications with good results.
http://www.facetmap.com/
Again, the ideas behind faceted classification deserve more attention, and I know I'm not doing them justice here. For an entertaining treatment of the subject by Clay Shirky, listen to "Ontology is Overrated":
http://itc.conversationsnetwork.org/shows/detail470.html
I may be misunderstanding you question, but isn't that very similar if not exactly what tags are for (as in stack overflow and gmail). Or are you looking for something more specific than that?
Ok, well, I tend to go on about this too much, but Tagging is just an example of what you can do with a triple graph, eg using RDF. [Insert Link To Wikipedia]. Now I know you said that tags are not enough, based on requirements for nesting, but there is no reason you cannot further "tag tags" as children of eachother.
Car|Tagged_with|Red
Red|Is_child_of|Colours
This way your data remains ultra-flexible, and really the divide between what is data, and what is metadata becomes blurred.
It seems like an issue that needs to be addressed especially for having users classify dimensional data into further, more simplified, dimensions (groups or categories whatever you want to call them) so that they can visualize the data better via the simplified categories/dimensions.
The user needs to be able to import a list, and both create dimensions for the list and then categorize the list intuitively based on those dimensions. Creating the dimensions would consist of naming/renaming the dimension (name of column) and then adding/renaming/removing the categories (column items) of that dimension. It should be seamless to switch between creating new dimensions and actually categorizing the list items individually or in bulk using the new dimensions created by the user. The user could then export the list with the additional column or columns (dimensions) containing the newly created categories.
The idea is that it would be much more user friendly that just having a table and adding columns to it. Ideally you would be able to select items in the list, and then assign them a validated category item from the user created dimension list which would auto-populate a read-only table that could be exported. Input = list, Output = comprehensively categorized list. No spreadsheet required.