WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 6 years ago

#3130 closed enhancement (wontfix)

Proposal for category improvements

Reported by: markjaquith Owned by: markjaquith
Milestone: Priority: normal
Severity: normal Version: 2.1
Component: Taxonomy Keywords: needs-patch
Focuses: Cc:

Description

Here is a quick mockup (non-functional HTML) of my category improvement idea:

http://img167.imageshack.us/img167/3561/picture3pz6.png

"Assigned categories" should be populated via AJAX, removed via AJAX. Category tree can and "Assigned categories" can work with each other... unchecking removes from assigned categories, or clicking the [x] removes the check. Ideally, you'd be able to hide either the flickr-like tag interface or the traditional category tree, so you could just use one or the other. Tags + Categories... best of both worlds.

Thoughts?

Attachments (2)

quickcategories-001.diff (5.4 KB) - added by markjaquith 12 years ago.
Work so far…
quickcategories-002.diff (8.6 KB) - added by markjaquith 12 years ago.
Patch for /trunk/

Download all attachments as: .zip

Change History (31)

#1 @ryan
12 years ago

I dig it. With disclousre triangles of some sort on each section I think it would be really sweet.

#2 @markjaquith
12 years ago

Another idea (someone else brought it up... maybe you, Ryan, but I'd been thinking the same thing):

Allow hierarchical category creation (including creation of non-existing parents).

I like the > character for that use.

We simply explode on ">" and then trim, and then start with array element 0 (N) and then go down the list. If element N doesn't exist on level N+1, we create it.

With non-hierarchical category entries for an existing category, we'd use the existing one (instead of creating a new top-level category). This logic would need some usability testing... there is potential for confusion.

#3 @markjaquith
12 years ago

Newest mockup:

http://img157.imageshack.us/img157/3766/picture1jc0.png

Why re-invent the wheel with show/hide stuff when DBX already does it?

The entire "Quick Categories" box is originally display: none; and if there is JS support it is displayed.

Still doesn't "do" anything. I may be over my head with the JS stuff, but I'll give it a stab.

@markjaquith
12 years ago

Work so far...

#4 @markjaquith
12 years ago

  • Owner changed from anonymous to markjaquith
  • Status changed from new to assigned

I'm calling it a night, but 001 is what I have so far. It adds and removes the items (adding categories if necessary), but it is interfering with the normal checkbox tree. It seems that the first onclick ajaxAdder() event to run "steals" the data, leaving it blank for the second one.

Skeltoac or mdawaffe probably can save me some head-bashing here.

Ideally, I'd like no disruption of the tree structure, although that may not be possible with the current code. I'd like it to just check the box. Eventually, I'd like it to be able to add parent and child in one submit and have it integrate into the current tree. Hey, a boy can dream.

I'm not sure if the ajax-adding should actually do the post2cat stuff... not sure how that'd integrate with the autosave and drafts and all that.

Ideally, the tree and the quick cats should be linked, so that adding/checking on either adds/checks on the other, and same for deletion. That may be tricky. My fallback would be to forget about updating the tree at all and just update the quickcats list. It could just insert hidden inputs and we can sort it all out with PHP on the other side.

Let me know if you have any thoughts.

@markjaquith
12 years ago

Patch for /trunk/

#5 @markjaquith
12 years ago

New patch uploaded. Video of it in action, and additional thoughts here:

http://markjaquith.wordpress.com/2006/09/18/wordpress-sneak-peek-quick-categories/

#6 @matt
12 years ago

  • Milestone changed from 2.1 to 2.2

#7 @foolswisdom
11 years ago

  • Milestone changed from 2.2 to 2.3

#8 @foolswisdom
11 years ago

  • Milestone changed from 2.3 to 2.4 (next)

#9 @pishmishy
10 years ago

  • Milestone changed from 2.5 to 2.6

Feature request so bumping to 2.6 for feature freeze.

#11 @Denis-de-Bernardy
9 years ago

  • Keywords needs-patch added

#13 @janeforshort
9 years ago

  • Component changed from Administration to Taxonomy

#14 @hakre
9 years ago

I like the idea, maybe some of the existing tabs on that subsection within the posts editor can be used nowadays (original mockup is a pre 2.8 UI). But I suggest to have this as a plugin first so that it can be better tested.

#15 @sjordan8
9 years ago

This needs fixed. Selecting categories that have children destroys the hierarchy.

Here are three screen captures illustrating the issue:

http://img340.imageshack.us/img340/6844/catsstep1.jpg

http://img127.imageshack.us/img127/1885/catsstep2.jpg

http://img99.imageshack.us/img99/7765/catsstep3.jpg

#16 @westi
9 years ago

  • Milestone changed from 2.9 to Future Release

As we are now feature frozen it is too late to include this into 2.9.

Moving to Future Release as there is currently no patch.

#17 @vteixeira
8 years ago

Someone please take a look at this. It's not an enhancement, this is a bug.

Let's smash those little bugs for wp 3.0.

It's been around for more than 3 years as I can see.

#18 @jane
8 years ago

@vteixeira: You don't understand the distinction between enhancements and bugs, then. Bugs are when something is broken and does not behave the way the developers mean it to. Enhancements are incremental improvements that could be made to the code or UI to make it work better or provide a better user experience. This is an enhancement. What @sjordan8 is saying is broken is not what this ticket is for, and should have been reported separately. I agree with hakre (shocker!) that this would be good to do as a plugin first so that we can (as Mark suggested) do some usability testing on the idea.

#19 @archon810
8 years ago

#10982 and #12312 marked as duplicates. I think this proposal is great and the current tiered category treatment is not ideal at all.

#20 @archon810
8 years ago

  • Cc admin@… added

#21 @vteixeira
8 years ago

@jane: I will post here the same thing I posted on another ticket but it was marked as duplicated ticket.

I think I must write what I think and why I'm calling this a bug:

If you want to put the post assigned categories at the top of the list this is OK, but it should never break the hierarchy, never.

Breaking the hierarchy confuses the user and makes it almost impossible in some circumstances to find the proper category to select.

When I have lots of categories this is even worst. If the post is assigned to the parent category and one child, the other child categories will appear at the bottom of the categories list totally isolated from the parent category making it very difficult to find them and to know that those categories are child of the one our post is assigned to. See the problem?

I have a test case (a site that I'm building right now) that beautifully illustrates the problem on the worst scenario: I have lots of child categories with the same names, ex: Parent1 -> national, international; Parent2 -> national, international; Parent3 -> national, international; So I have different Parent categories names but the same child category names for each parent category. How am I supposed to find the correct child category to apply for my parent category?

Usability bug.

What really confuses me is that on the post quick edit the categories are OK (it's just not indented), the problem is just on the Edit post screen.

Just something I want to add: there are two tabs on the categories box on the edit post page -> All Categories and Most Used. If you select the Most Used tab it will already show the assigned categories at the top without hierarchy, so why should the All Categories tab break the hierarchy to show the assigned categories at the top? It's already done on the other tab!

Let's keep it the way it is intended to be: a list of categories and subcategories - respecting the hierarchy, please.

This is a real usability problem.

Scribu already made a plugin correcting this: Category Checklist Tree

But we just want to see it on the core.

#22 @vteixeira
8 years ago

@jane: if you don't know what I'm talking about take a look at the Ticket #10982.

Unfortunately it was incorrectly marked as a duplicate of this one.

This folding and ajax stuff is really an enhancement but what I wrote above is a bug.

We are just reporting it here because the ticket that reports this bug is always marked as duplicated. What can we do?

#23 @jane
8 years ago

@vteixeira: In WordPress core development, on Trac, "defect (bug)" refers to code glitches only. If there is a usability issue, it is an enhancement. It would only be a bug if the developers tried to code it to do one thing and instead it did another (which would be a code glitch). I agree that breaking hierarchy is bad, and we should fix it, but it's important to use the correct labels in Trac to keep things moving correctly. Usability issues = enhancements, broken code = bug. You can argue that it shouldn't be that way, but it's how it is, at least for now, so please use the terms in this manner. Thanks.

#24 @vteixeira
8 years ago

@jane: OK, I'm new here. Maybe I just wanted to make it sound more like a problem by calling this a bug.

Glad you see the problem with breaking the hierarchy.

#25 @kevinB
8 years ago

  • Cc kevinB added

#26 @maorb
8 years ago

  • Cc maorb added

#27 @maorb
8 years ago

Do you know if there are plans to put this enhancement in the core?

#28 @aaroncampbell
8 years ago

  • Cc aaroncampbell added

#29 @scribu
6 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from accepted to closed

After 5 years of back-and-forth, I don't think we can come to a consensus on this, so let's just add a filter to make it super-easy for plugins to turn this on or off: #20054

Note: See TracTickets for help on using tickets.