WTF do we need form types for?

Bloke · 2015-08-02 22:05:08

jakob wrote #293858:

Would making themes and page templates assignable on a per-section basis mean that as a themes designer you need to break down your styles for per-section use accordingly?

Not necessarily. You may have missed the post about the various options buried in the Theme discussion thread. But the overwhelming response was to go for the path of least resistance: manual assignment.

Sidestepping Bert’s simplification of a theme only being one Page/Style, a Theme at its most basic level is an independent collection of Pages, Forms and Stylesheets. As a designer, that’s the primary focus: make the site look and work in a particular fashion, with the assumption that it will be the sole Theme in use on anyone’s site. People who install that theme then assign it to one or more of their existing Sections and it shows up on the public site when the relevant content is viewed.

Now if a particular person likes the look of two Themes, great. Install both. Assign Theme A to three Sections and Theme B to a fourth. It’s not your job as the designer to anticipate this split. It’s up to the person who decided to employ two Themes to unify the look and feel so their menu structures work. Theme B just gives them a leg-up so they don’t need to start from scratch if some Sections of their site demand a significantly different layout that Theme A doesn’t fit as well.

If, however, you as a designer had a multi-faceted Theme in mind, then by all means go to town. Create one Theme containing many Pages/Forms/Stylesheets that all inter-relate and give them suitable sectionish names to indicate their intended usage. That way, people can assign the appropriate Page/Style to the Sections that best fit their site divisions.

Textpattern cold make this process more flexible. I had envisaged that if you viewed Section A which was assigned to Theme A (and therefore only had access to Page set A, Stylesheet set A, and Form set A) then any call to <txp:css /> without the name, for example, would render the CSS from that Theme. If you added the name attribute it would have to match the name of a stylesheet in the Theme that was assigned to the Section. Since the assets in the Theme have been designed to work together, the designer has used the correct names in the templates, so everything just works, as long as the person who is using the theme doesn’t make any sweeping changes. But if they do, well, that’s their prerogative, and smd_where_used becomes their next best friend.

This is a slightly inflexible approach insofar as there is no way to refer to any asset outside the Theme in which it’s defined. Perhaps this could be relaxed by adding an optional theme attribute to <txp:css /> and <txp:output_form />. That would at least permit someone who did wish to employ multiple Themes to pull out, say, the navigational elements and Styles into separate assets in one of the Themes and cross-link to them from any other installed Theme.

Not sure where that leaves the form attribute in other tags, as those would be confined to the Theme in which they were used. But that’s not really a bad thing as they tend to be presentational within the context of a Theme for displaying lists of things and formatting content. All the theme attribute would do would be to permit cross-linking of essential building blocks: something that (ummm, I think) only makes sense to do with <txp:css /> and <txp:output_form /> tags.

Would that sort of address your concern, or have I missed the point?

michaelkpate · 2015-08-03 14:47:53

Bloke wrote #293914:

This is a slightly inflexible approach insofar as there is no way to refer to any asset outside the Theme in which it’s defined. Perhaps this could be relaxed by adding an optional theme attribute to <txp:css /> and <txp:output_form />. That would at least permit someone who did wish to employ multiple Themes to pull out, say, the navigational elements and Styles into separate assets in one of the Themes and cross-link to them from any other installed Theme.

All the theme attribute would do would be to permit cross-linking of essential building blocks: something that (ummm, I think) only makes sense to do with <txp:css /> and <txp:output_form /> tags.

I that could be very useful. The main thing I have been worrying about is not having namespace collisions between forms in two different themes.

Perhaps there could be a way to enhance the duplicate option to transfer between themes (although copy and paste works easily enough).

candyman · 2015-08-03 16:06:13

Destry wrote #293878:

Outdated documentation and buried forum threads is no reason to not improve the usability of the system.

Snippets, Partials, Trouser Snakes… one of them has to be more universally understood as “includes” than Forms.

We have to see if the advantage that we gain simply changing a name (from Forms to wordchoice) will deserve all the disadvantages that that change will port.

The changing of the name, according to me, is would not be a great step forward. The updating of all the docs and the buring of all unuseful threads (if so we can call them) would make sense only if due to an epocal change.

We all know what Forms are, don’t we? Are you sure that changing a name into another will improve the usability? I think it will lead to more confusion to the newcomer that will find some tips that now are usefull, ununderstandable.

Last edited by candyman (2015-08-03 16:17:10)

michaelkpate · 2015-08-03 18:28:06

candyman wrote #293919:

We all know what Forms are, don’t we? Are you sure that changing a name into another will improve the usability? I think it will lead to more confusion to the newcomer that will find some tips that now are usefull, ununderstandable.

I think most people know what forms are.

A webform, web form or HTML form on a web page allows a user to enter data that is sent to a server for processing. Forms can resemble paper or database forms because web users fill out the forms using checkboxes, radio buttons, or text fields. For example, forms can be used to enter shipping or credit card data to order a product, or can be used to retrieve search results from a search engine. – Form

But not perhaps the way Textpattern defines them.

Textpattern Forms are predefined portions of text, Textpattern Tags, and/or HTML, which collectively define how content should be formatted and displayed. Textpattern forms are easily created in the Forms panel. Forms are used by the Tags that call them, via the form=”“ attribute. Once you have a good grasp of Tags, Forms, and the relationship between, you’ll begin to realize the seeming endless possibilities of how to customize your website’s architecture and content. – (Forms Explained)

jakob · 2015-08-10 12:39:09

Bloke wrote #293914:

Not necessarily. You may have missed the post about the various options buried in the Theme discussion thread. But the overwhelming response was to go for the path of least resistance: manual assignment.

Sorry for the late reply: I was away last week and unable to reply. Thanks for clarifying the thinking behind it.

I see the advantages in being able to “bolt on” different theme components from other themes rather than switch and discard what is already okay. I still wonder if it will lead to problems in how people ‘expect’ themes to behave and in helping people on the forum (we’ll need to ask “what theme(s) are you using for which section(s)?” or “…for the section in question” rather than “what theme are you using?”) but I suppose that depends on what the received notion of a theme is, and that may be a matter of how it is communicated.

I like the idea of a coordinated set of themes, and I guess there it makes sense to split css into core and section/functionality css.

maverick · 2015-08-10 15:59:07

jakob wrote #294048:

but I suppose that depends on what the received notion of a theme is, and that may be a matter of how it is communicated.

I’m supportive of a section by section approach, which we functionally have now. I also am supportive of having section agnostic options for code; so when it needs to be included regardless of themes/sections it can be. Again, which functionally we can do now. To the simple minded as myself, the change is really about organization – how to group and name these without losing current functionality.

That said, I too am cautious about support and troubleshooting. From that perspective is seems like complications might be ahead.

So letting my inside thoughts outside :P

Right now we treat pages and forms from an editor paradigm (which I’m a fan of – I use the editors :D). The editor is front and center, and the list of pages, or forms, or CSS are off to the side. From a screen real estate perspective, it can be high-density.

What if there was a tab or three (I’d lean to a single unified tab divided by page/form/css, each section capable of collapsing) showing each page, form, and css in a grid; page/form/css name on the left, and a used by to the right, with every place it is used listed. With the advent of templates/themes/packages/etc. it would be a quick and fast way to find out this form is being used by two themes. This css is being used by all the themes. This page is being used by this section(s)

Perhaps this is plugin territory and I know smd_where_used can be installed for some if not all of this and more. But to be visually focused this way might go a long way to managing the junction of themes with pages/forms/css and give a tool for help discussions.

fwiw

Last edited by maverick (2015-08-10 16:01:40)

Bloke · 2015-08-10 18:18:29

maverick wrote #294050:

page/form/css name on the left, and a used by to the right, with every place it is used listed.

In the current implementation of the Themes panel, if you hit the Show detail checkbox, you get three additional columns showing you the number of Pages, Forms and Stylesheets assigned to that Theme. Each number is hyperlinked to the relevant panel which filters the list based on the Theme so you can see at a glance what’s used.

It doesn’t list individual assets all on one panel so you can’t easily see what’s shared, but it’s consistent with other UI paradigms we have about the patch (e.g. to show the Comments assigned to an Article, or to show Articles assigned to a Section). Anything above this feels like plugin territory to me, but I can be swayed if there’s a compelling argument.

Regarding potential support issues, once you’ve picked a Theme to work on (i.e. chosen one from the dropdown on either the Pages, Forms or Styles panels) it’s remembered as you navigate around the place so all you see on each panel are the assets assigned to the currently selected Theme.

Also, on the Sections panel, you see the Theme name in addition to the Page and Stylesheet in use in the columns of the table. Again, you can click on the Theme name which’ll (currently) take you to the Themes panel with that one filtered (and shows all the asset counts too) and sets the Theme you chose to be the one currently being edited (at least I think that’s what I did: will need to check).

I’m hoping these two UI hints in tandem will minimise confusion because you pick what you want to work on and it remains current until you change it.

Any enhancements on this UI workflow I’ll consider if it makes sense to the majority of users, bearing in mind that most will probably only have one or, at most, two Themes installed anyway.

maverick · 2015-08-10 19:02:50

I should have know you would be way ahead on this, Stef. :)

That sounds like enough, and better. Since most will only have one theme, or maybe two, and there will be few shared forms/css, my brainstorming was overkill. This is much more elegant given actual use cases.

Thank you for describing it. I need find time to play with the new version :)

Bloke · 2015-08-10 21:23:25

maverick wrote #294064:

That sounds like enough, and better. Since most will only have one theme, or maybe two, and there will be few shared forms/css, my brainstorming was overkill.

Actually, there’s one more anti-feature I forgot to mention. If you have only one Theme installed, it looks identical to how it does now. No additional UI widgets anywhere except for the Themes panel and the name of the theme in the Sections panel columns. The dropdowns elsewhere all disappear since you have Hobson’s choice.

I need find time to play with the new version :)

Yes please. Would like to hear your thoughts on the branch. But note that I still need Phil to do some CSS work and/or suggest a position/suitable markup for the (currently mostly obscured) Theme dropdowns. And I haven’t added the file system sync stuff yet as it’s only partially implemented on my local box at the moment.

Textpattern CMS

Textpattern CMS support forum

#31 2015-08-02 22:05:08

Re: WTF do we need form types for?

jakob wrote #293858:

#32 2015-08-03 14:47:53

Re: WTF do we need form types for?

Bloke wrote #293914:

#33 2015-08-03 16:06:13

Re: WTF do we need form types for?

Destry wrote #293878:

#34 2015-08-03 18:28:06

Re: WTF do we need form types for?

candyman wrote #293919:

#35 2015-08-10 12:39:09

Re: WTF do we need form types for?

Bloke wrote #293914:

#36 2015-08-10 15:59:07

Re: WTF do we need form types for?

jakob wrote #294048:

#37 2015-08-10 18:18:29

Re: WTF do we need form types for?

maverick wrote #294050:

#38 2015-08-10 19:02:50

Re: WTF do we need form types for?

#39 2015-08-10 21:23:25

Re: WTF do we need form types for?

maverick wrote #294064:

Board footer