Rethinking form types

Destry · 2015-11-26 13:03:36

Now that form types are nothing more than form organization categories baked into the UI, it makes more sense to change the organizational functionality so that:

There’s no categories by default (all default forms just list alphabetically in sidebar)
The form type assignment controls become form type creation controls (so instead of selecting a baked-in category, you create the category label you want, which then appears in the sidebar with the form underneath it.
You can create as many type categories as you need.

You can then re-position any other form — defaults or any form you build later — to any new form type category by either assigning it to one you’ve created, or creating a new type category as needed.

Why is this good? Because as it is, the baked-in form types screw with people’s mental models, as demonstrated here (but not only). There’s too much false impression via the existing baked-in type categories that a form must belong to a certain type in order to function correctly. That’s not the case anymore, if I’m not mistaken, so that condition that causes the false impression should be removed. A new ‘categories-by-design’ process would solve that easily.

michaelkpate · 2015-11-26 17:55:11

+1 Million – I have wanted this from the beginning.

ruud · 2015-11-26 19:13:50

+1
I suspect this affects the tagbuilder, which (IIRC) uses the form type to show only relevant forms.

philwareham · 2015-11-26 21:17:52

The tag builder, hmmm. I’m hoping that can be omitted from Textpattern 4.6 entirely. That’s a conversation that needs to be had.

Bloke · 2015-11-26 22:51:00

This is something I’ve done about three times now in various guises and it’s never been satisfactory so I’ve binned the work each time.

There are a few niggling little Txpisms that get in the way of refactoring this in a manner along the lines that Destry proposes:

Article forms are still “special” insofar as they appear on the Write panel as override forms. This permits you to use any of the Article-type Forms as your article’s Form — on an article by article basis — instead of the one that the template would usually dictate. A very handy feature because it gives content authors the option to effectively change the layout of an article within a Section by choosing from a set of pre-defined Forms in the list under the Advanced twisty. Removing the Article group would mean all Forms get listed there, which is a) not useful, and b) not useful.
Essential forms. These blighters are what help give Textpattern the notion of convention over configuration and simplifies the back-end code because we know a-priori that a certain form must exist so don’t need to defend against it and handle errors in the event of its non-existence. Granted, the types don’t actually matter that much, aside from default always having to live in the ‘Article’ group, but the way they are defined in the code and assigned to their default groups is kinda limiting because every page load resets the list and it has to be overridden each time, which is a waste of processor cycles.
Multi-edit ‘reassign to different Form type’ is more complicated if you add a new type. Should it only permit you to choose from the ones you’ve already created (which is kinda limiting and potentially confusing), or should you be able to say “Move all the checked Forms to a new group and call it Toolbox”. The UI for this is cumbersome to conceive.

I’ve approached it in a number of ways over the years:

Add a box alongside the existing dropdown. If you leave the dropdown empty and type a value into the adjacent box, it’ll use that name instead and will therefore add it to the dropdown list from then on. Similarly if you remove all articles from a group, the group name disappears from the list. If you type the name of an already existing group, well, it goes in that one anyway.
Add a ‘New Type’ link alongside the dropdown. When clicked, that either adds the input box mentioned above to the DOM via jQuery to ask you for the new group name and then adds it to the dropdown if necessary (again via jQuery), auto-selecting it since that’s likely the action you want to take.
Same as above but as a popup dialog instead.

And I’m sure a few besides. In all cases, what seems like a simple alteration becomes far more difficult than it should be. I get so far and one of the aforementioned Txpisms sticks its oar in and makes it much harder than necessary. So I’ve come to the conclusion that in order to do this feature request justice, something fundamental has to change about the way we handle Forms.

The simplest way might seem on the surface to remove the notion of ‘group’ for the essential Forms so the code knows which ones must exist, but doesn’t care to which group they are assigned. You should then be free to reassign as you see fit. But those pesky Article forms get in the way because the essential forms under that group MUST remain there (at present). And you can’t just have a free-for-all- list of form names without some notion of their default group, otherwise your Override Form list gets cluttered with Forms that don’t make sense to override an article. And if you hard-code some or all of the Forms in a particular group, they can’t be moved, which makes the UX more confusing (“Why can’t I move this one, dammit?”)

I don’t know the best way forward. Certainly the documentation in the above linked example is confusing. It shouldn’t refer to an ‘image form’, just a Form. This could also be mitigated a little with some better contextual documentation on the Forms panel (inline, or behind a ‘?’) explaining that in 95% of cases, the types are for your own organisational benefit and serve no other purpose. The exception being the Article type.

As I say, I keep coming back to this and having a stab at changing it, but it’s never managed to be a worthy fit. Always appears like an afterthought (which it is!) or creates a confusing UX workflow (e.g. “why are there two boxes for Type?”)

I. Just. Don’t. Know. Anyone who wants to have a crack at it, be my guest.

tye · 2015-11-26 23:23:11

philwareham wrote #296849:

The tag builder, hmmm. I’m hoping that can be omitted from Textpattern 4.6 entirely. That’s a conversation that needs to be had.

You know… I used to not like the tag builder… but having worked with Drupal views and Wordpress wp-types…. I think txp was probably way ahead of the pack back in the day…. maybe we should improve tag builder to become form builder ;)

Article form overides are cool for creating different post types

Last edited by tye (2015-11-26 23:24:48)

Destry · 2015-11-27 10:07:51

Bloke wrote #296851:

There are a few niggling little Txpisms that get in the way of refactoring this…

Bugger.

I think even a compromise in the right direction would be something. What if the Article type (let’s call these classifiers instead of types and categories, for better distinction and fit) was kept as is for reasons you describe, and all other classifiers were removed and followed a model similar to what I described.

So a default install might see the Article classifier, with the typical article forms under it, and that classifier would be in the classifier list by default too (the only one). This Article label in the sidebar would have an “info” icon next to it explaining its function in relation to the form override in the Write panel (which could be added there now for improved usability).

Then the other default forms would be under a second stand-in classifier called, say, “To classify” (assuming they function just fine without dependency on this classifier label). This sidebar label would have an “info” icon next to it explaining that one can create new form classifiers to organize new and existing non-article forms.

The classifier controls then work as mentioned:

you can create as many as you need by whatever name,
assign new forms to whatever new classifier
move “To classify” forms to any new classifier

When all forms have been relocated out of “To classify” that label disappears permanently.

Something like that?

Bloke · 2015-11-27 20:00:44

Destry wrote #296859:

Something like that?

Definitely a step in the right direction. Sounds mostly reasonable so I’m up for exploring the idea. How would you (or anyone here?) approach the UI/UX under this new paradigm? The key parts to think about are:

Retaining the ability to rapidly classify / reclassify a Form. A select list works well, but is there something better?
The ability to add new classifications easily and intuitively. Permanent UI element, or tap-to-reveal, or …?
Multi-editing Forms to move them all into either a) existing, b) new classifiers.
The multi-edit tool currently does not have checkboxes alongside essential Forms, which prevents them being a) moved, b) deleted. If they are allowed to be moved (adding a checkbox), how do you prevent someone — from a cognitive perspective — seeing the checkboxes and thinking the multi-edit’s Delete function will apply? This ties in with,,,
… preventing the reclassification of essential Forms that must remain in the Articles classifier. Presumably just omit various UI controls if editing one of these Forms, like we do now.

Mockups or detailed descriptions of workflow welcome as it’s not my area of expertise.

philwareham · 2015-11-28 08:00:37

If you want UI mockup from me it’ll have to wait until after 4.6 release as I have much to do already. It makes sense to explore this issue at that point anyway since the theme feature will change how forms/pages/styles are handled somewhat anyway. Raise a GitHub issue that point back to this forum topic and I will flag it as a 4.7 milestone request.

Destry · 2015-11-28 11:12:04

Definitely something to schedule against the existing roadmap, which means later.

That said, I’d be careful not trying to overthink the design of it. If you can make it work using the existing form creation controls, but just changing the underlying mechanics, that would be good enough.

But, stick to the 4.6 roadmap. ;)

Textpattern CMS

Textpattern CMS support forum

#1 2015-11-26 13:03:36