bgarrels / textpattern

Automatically exported from code.google.com/p/textpattern
0 stars 0 forks source link

Specify category title and name on creation #393

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
When a category is created, only the name is requested; the title is assumed to 
be the same as the name. This causes problems where there are nested categories 
with common entries, e.g.:

Colours
- Yellow
- Orange
- Red

Fruits
- Apple
- Banana
- Orange

A workaround for the user is to have a unique name and optionally different 
title; this satisfies the requirements for uniqueness in the name and gives 
options for appropriate front-end markup to mimic the lists above.

On category creation, I am asked for the name of the category. If this is a 
duplicate name (say, Orange), the category will, rightly, not be created. In 
the 4.5.4 classic theme, sections can be created with name *and* title provided 
at the time of creation. If this option was available to categories at creation 
time, a unique name (say, colours-orange) could be applied, along with a pretty 
title (you guessed it: Orange) for the front-end.

Original issue reported on code.google.com by gaek...@gmail.com on 26 Aug 2013 at 8:45

GoogleCodeExporter commented 9 years ago
Thanks for raising this. It comes under the banner of 'hmmmm'. I can see valid 
reasons for adding both a name and title option, but equally, it could create 
usability issues unless something else changes with it. The question is going 
to be how to address it sensibly.

For example, before you can create a new Section, you need to click the 'Add 
Section' button, which then displays the input fields. On the Categories panel 
the 'new' fields are inline. Adding a third input box at the top of each column 
pushes the category list further down the screen, which introduces extra 
scrolling.

Arguably, there a few ways out of this. Perhaps remove the inline 'New 
category' elements altogether and put them in a separate step, like they are on 
the Sections panel. That adds one extra click to the category creation and 
hurts the 'rapid category' system that allows you to add multiple categories 
under the same parent without having to reselect the parent each time.

Alternatively, add the new 'name' element and allow the block of 'New category' 
input elements to be collapsible to save screen real estate. Debate can rage 
over whether this behaviour should be per category type or a single control 
that shows/hides all input elements at once across all four types. Or both.

Clouding these issues are items such as:

* Should the new element be mandatory.
* Could the workflow be improved via AJAX or drag/drop.
* Could the entire Categories panel be rethought with better UX (probably!) 
while still retaining the ability to see the at-a-glance hierarchies.

I've no doubt that the panel needs to be improved. Multi-edit and multi-click 
checkboxes work, but there's no filtering ability (search), no way to just show 
descendents of one or more ancestors, nor is there a way to collapse branches 
of the tree. Having the ability to switch to displaying a category list in some 
tabular format -- akin to the Sections panel -- would be a boon for sorting and 
filtering, and maybe some multi-edit actions, but a table-based layout isn't 
conducive to seeing the hierarchy. Both have their place.

Creating the same category in two or more groups is also something that 
sometimes crops up (to tie an image gallery to an article, for example) and 
requires the user to create the category many times. Maybe a single 'create 
category' control panel with a multi-select list/checkbox set of which groups 
to create the category can be implemented instead, with the selection being 
remembered after submission. Though that does complicate the 'parent' aspect of 
things, so might not be viable.

With regards making the 'name' mandatory, if it is then it's a chore to have to 
enter the same info, almost identically, twice for each category. That's a 
weakness of the Sections panel in my view and where the Category panel is 
better: you can just enter "Oranges" in the cat panel and it'll create your 
category with an "oranges/Oranges" name/title. But on the Sections panel, if 
you omit the 'name' field you get an error. And, worse, you're dumped back to 
the Section List view and have to then click 'New Section' again and re-enter 
all the info. Grrrrr.

I'd much prefer if the Section Title was offered first, with the name 
automatically taking on the dumbed-down version of the Title (either by some 
jQuery script filling in the Section name as you type, or being dumbed down 
upon form submission if the name is empty). That same idea could be extended to 
the Category panel so the auto-naming behaves as it does now, but with the 
option to override it manually if you wish.

And some way to stay on the edit step if there's a name clash would be better 
UX imho. Or at least some kind of warning that there's going to be a problem if 
you do click Save. Or even, upon submission, trying to create the category 
name, but if it fails, attempt to automatically prepend the parent to the name 
and try again. Though making such assumptions on a user's behalf is not 
particularly good design practice.

Lots to think about. Yes, not being able to specify the Category name could be 
a deficiency in some cases, but in maybe 90% of other cases the Category panel 
works, if just a little clunky. So if we're going to add such features we need 
to tread carefully to improve the overall power of the Category panel without 
introducing too many extra clicks or obstacles that impair rapid category 
creation.

How's that?!

Original comment by stefdawson on 29 Aug 2013 at 11:40

GoogleCodeExporter commented 9 years ago
Regarding the look of the category page. The category lists should IMHO follow 
the same format as other list pages, i.e. be in tables and have search 
functionality (our 4.6 markup allows multiple txp-list tables in a page now). I 
can mock up some examples if needed (possibly in a couple of days time - I'm 
away from computer at the moment).

Original comment by flaming....@mac.com on 30 Aug 2013 at 6:42