Bug 3459 - new styles categorization system (brainstorming + RFC)

[momijizukamori]

(Apologies to anyone seeing this twice, I posted it in dw_dev_training but Mark and D suggested here was probably a better fit!)

So, this is the gigantic project that's been kicking around my head the last few months, because I love our themes but right now, the organization is nooooot there. And I love organization. The full bugzilla listing has all the debates and links and what not, but I'm going to add the summary of UI implementation I ran by Denise below:


"Okay, some more thoughts how to lay this out and a super-rough 'needs input and feedback' list from my head:

Featured
All
Popular
> Base Layouts
-Abstractia
-Bannering
-Bases
-Basic Boxes
-etc..

> Colors
-Black
-White
-Grey
-Brown
-Red
-Orange
-Yellow
-Green
-Blue
-Purple

> Accessibility
-Dark on Light
-Light on Dark
-High Contrast
-Low Contrast
-Bright
-Muted
-Non-default text-styling*
-Textured background*

> Default layout
-One-column
-Two-column
-Three-column

> Style*
-Winter
-Spring
-Summer
-Fall
-Aquatic
-Nature
-Animals
-Clean

Anything with an '>' would be a fold-out, so it'd be like:

Featured
All
Popular
> Base Layouts
> Colors
v Accessibility
[ ] Dark on Light
[ ] Light on Dark
[x] High Contrast
[ ] Low Contrast
[ ] Bright
[x] Muted
[ ] Non-default text-styling*
[ ] Textured background*

> Default layout
> Style

with checkboxes for options within a grouping-category. Talking with Dre about this, she thought that if we're only nesting one deep, we probably don't have to write new code for sub-categories, and can split it out like we do tags instead.

The non-expanding stuff at the top and possibly 'Base Layouts' should be links on their own - all other grouping categories don't make much sense as categories on their own (given that 'Colors', for instance, encompasses ALL COLORS).

I think the most intuitive selection process would put multiple selections within a category as 'or' matching, and selections in different categories as 'and' matching, if we don't want to deal with coding an 'and/or/except' selector right now (though that might be a good improvement). So you could say I want a layout that is red OR orange AND has two-columns AND is dark-on-light.

...stuff I have under accessibility right now might be things people want 'AND' matching on (muted AND dark-on-light) :S Not sure how to deal with that."

(If you think this bears a distinct resemblance to the Ravelry advanced search you would be right).


Because the scope of this runs through Perl, MySQL, BML, and Javascript, today I sat down and wrote out a vague work-flow for how looking at themes by category in /customize should run, and how adding themes as an admin should run, so I have an idea of what I need to do.


Looking at themes
Front-end: /customize/index.bml
-remove ?cat= links for navigating categories
-expanding/collapsing menu = JS
-checkboxes for selection and AND/OR/NOT drop-down, 'Clear' button
-Refresh options on select without reloading whole page = Ajax?

CONNECTION - send request to the perl subs, get back list of what to display.

Back-end: LJ::S2Theme
-implement extra search functions: AND NOT OR
-should support multiple cats per call - expand on LJ::S2Theme::load_by_cat()

CONNECTION - cache catids from SQL for easy loading (already implemented)

Storage: SQL database
-two options:
-use 'category: subcategory' style formatting, and build heirarchy in the code
-make new s2subcategories table in database

Adding themes to categories

Front-end: /admin/themes
- current implementation is clunky
- needs preview grid, pagination (similar to /customize?)
- parent categories that aren't in of themselves a category shouldn't show on drop down (ie, Colors)

CONNECTION - already implemented for basic categories, may need changing depending on format

Back-end: LJ::S2Theme
-need scripting to automate categorization tasks that can be automated (most color info)
-Depending on category storage, may need new storage functions for db.

CONNECTION - adding new themes to categories in db
-When to run scripting for auto-adds? on db update?


I'd really appreciate feedback on if I missed any important stuff, logistics of the UI implementation, and how exactly we should store this information in the databases. Or even on the list of categories I have so far, though there will probably be a bigger, more official RFC when things get far enough.