User discussion
It might be nice to have sub categories. For example 'Book' is becoming a large category. It might be nice to split it into sub categories - such as fiction and non-fiction.
DanFr: This is a great idea. We struggled with this for awhile, and decided that a "category" had to do with what fields were present, while a "subcategory" could be handled by an attribute (e.g., subcategory: Fiction) and some searching or a simple navigation-along-attributes interface. Clearly, there is more work to do than the current state of things. (added at 02:35:46 PM on 04/19/05)
KurtWilms: Wow, are sub categories going to become a reality? This is something I personally thought would be very cool (and useful!), keep up the good work! (added at 11:25:44 PM on 10/11/05)
Lando: I approached this dilemma with simple try and learn -method. I created 24-page in TV show-category and added category plugin in that 24-page. It changed that page into category of it's own. I also made 24/Fields-page and linked that to 24-categorial page (with ConfigureThisCtaegory-feature). After that it was simple to add pages (with CreatePage-feature) in that newly created category. I assume that order of those steps must be just like I explained, because I don't know how to link already existing pages in some category, it is easiere to first create category and use CreatePage-feature in that category-page. (added at 10:25:43 AM on 02/01/06)
Developer discussion
This issue is exacerbated by restaurants. We now have
- 4 restaurant categories (because they are appearing by city/metro area)
- restaurants of different cities (and countries!) in the Restaurant category, whereas many people will only be interested in the restaurants near them. Several "local" categories would have this problem, although Restaurant is our only existing example.
DanFr proposes:
The "city" field be used as a subcategory
The "neighborhood" field might then have to be dependent on the "city" field. That is, each city has its own neighborhoods.
- This requires a Field spec for dependence.
- This requires (probably Javascript) changes to the editing interface to display only the appropriate values of a dependent field (or probably none if the driving field has nothing selected). That is, if no City is selected, there should be no display of Neighborhood, and when a City is selected, then Neighborhood must display the right values).
- All restaurants be folded into the "Restaurant" category
- The category page have a simple way of seeing and selecting (at least top-level) subcategories. Proposed interface:
Subcategories: city: Minneapolis (20) Seattle (5) San Francisco (10) <more...> cuisine: Chinese (30) Thai (10) Italian (5) <more...> Recommendations: <current list of pages with prediction and buddy annotations...> To add to the category: <current text...>
Each of these cities would be a clickable link that would filter the results down to the subcategory.
MaxHarper: You've defined a filtering approach to sub-categorization, which seems easy and good. I'll propose an alternative, not because it's better, but because it's what I originally thought of when I saw sub-cats. Sub-cats could extend categories like sub-classes extend classes in an OO programming language. Then, you're modelling an "is a" relationship; you can extend or override fields. Thus, video-games might sub-class software, and add or override a few fields.
DanCo: Specifying certain fields as quick filters that the interface automatically blows out for you to select on sounds good. Cuisine is a fine example. City is a little more problematic: what if I want a restaurant in the twin cities? -- but still reasonable.
Other Questions
Should sort of subcategory displays be by popularity, or something more predictable like alphabetical?
- TonyLam: I would propose something predictable. Trying to find anything outside of the top few would become a chore, and probably not everything here is going to be power law distribution. It would also just look weird for some subcategories, especially numerical ones (e.g. if cost were a subcategory: $$ (20) $$$ (13) $ (10) $$$$ (4))
- DanCo: Could be part of the field definition, how to sort (popularity, predicted liking of each subcategory, alpha).
Perhaps these clicks would be combinable with AND? That is, cuisine would also be a subcategory, and clicking first on Minneapolis would restrict to Minneapolis, then clicking on Chinese would restrict to Minneapolis Chinese. Could this be deferred?
- TonyLam: Feels like you could do this relatively easily with CategoryFieldSearch? Might not perform well tho.
- MaxHarper: It depends on the interface. Unless it makes it very clear that you're refining the search, it should not refine.
- DanCo: Refining feels almost necessary. BTW, I looked but couldn't figure out how to search in a category.
Should each subcategory field have a way of marking it in the field spec as "for display on the category page"? Perhaps have all restricted-value fields (i.e., fields with "Options" on their fields page) automagically listed.
- TonyLam: I worry a little about having complex default "policies" for this, but yeah, I think "opt-in" to display for unrestricted fields and "opt-out" for restricted fields might be reasonable.
- MaxHarper: default should be no sub-categories. yes, modifying field definitions seems like the best way for sub-cats.
- DanCo: Agree that it should be part of the spec.
What should the Field syntax of "dependent" fields look like? That is, there has to be a way to say "Neighborhood depends on City" and "here are the neighborhoods for Minneapolis". Options:
Combined: list under City its dependent field (Neighborhood), and list Neighborhood values under the "Options" for the City, nested further in
- TonyLam: If I had to choose, I would say combined. It more readily extends to multiple dependence, which may or may not be inevitable once we go down the sub-categorization path (ugh). Any thoughts about not imposing too much hierarchy and instead going to a more tag-like system?
- Separate: Have Neighborhood declare its dependence on City. Have it list its dependent values under City entries in its Neighborhood Options
- DanCo: How often are there going to be dependent fields? City on State, Neighborhood on City... is it mostly related to places?
Should we defer dependent fields? If yes, we could do the rest faster, but would have to give up reasonable display of Neighborhood
- delete Neighborhood as a Restaurant field for the moment
- Have neighborhood, but not dependent (that is, every city's neighborhoods would get mixed together)
- TonyLam: deleting the field seems wrong... I would rather see it become freeform text (tags?) or something in the interim if its deferred
- DanCo: How about not having a quick filter on Neighborhood?
How to "save" a restricted view? For example, perhaps I wish to have Restaurant show City=Minneapolis by default all the time. Probably the URL will be explicit about filtering, hence could be bookmarked, but it would be nice to have something explicitly in the system. Of course, this is more building expense. How important is this?
- TonyLam: I would be a little concerned about the front page and the side bar, both of which seem to be rather important for navigating around WikiLens. Clicking Albums and getting all albums from all genres isn't quite so bad (although one might imagine Martians overrunning WikiLens and filling the Album category with all manner of Martian new age and death metal), but getting restaurants from all over the world when clicking on Restaurants might be annoying. The front-page recommendations would also lose their value quickly in a consolidated and unrestricted Restaurant category.
- MaxHarper: probably a convenience feature, not critical. I can still filter/search.
- DanCo: until it's used a lot, not a huge issue. Once it is, the answer may be obvious.
Speed? This is just wondering aloud if the filtering to produce the clickable subcategory listing will be incredibly slow and require optimization.