Modular Content

Bloke · 2014-04-08 00:01:22

giz wrote #280123:

Has anyone tried Medium?

Not yet, but it’s on my list of things to try, even just for the bloody-mindedness of seeing how it works and if there’s anything we can steal for Textpattern :-)

Bloke · 2014-04-08 00:19:33

Interesting side note on this topis: one of my colleagues wanted a website for one of the products we sell. He installed WordPress because he’d heard of it, downloaded and installed a theme, and then hit a roadblock. “Why doesn’t the site look like the theme preview screenshot”? was the first question. Then, after some frustrated mouse clicks and sighs, “Why is making websites so hard? I just want this description here alongside this image. I should be able to drag it from my desktop and it should appear there” (pointing at the screen).

I was kind of internally rolling my eyes, but he had a point. In this day of touch, swipe, play, why is the barrier for website creation so high? We at the sharp end know it’s because there’s a truckload more going on behind the scenes and there’s more to design than point ‘n’ tap. But to the novice who can muck around in Fireworks, it’s frustrating.

Of course, he gave up and I was drafted in to try to get the website at least working. For my first foray into WordPress for over 8 years, overall I found the interface bafflingly convoluted, though one or two things were very nice ideas I’d love to port to Txp.

Conversely, in a couple of days of sporadic e-mail exchanges across timezones (and some sprinkled adi_notes goodness), I’ve helped a 72-year-old grandmother with a print background grasp how to create and manage content in Textpattern, and she’s tinkering and experimenting with pages and stylesheets to lay out her website as I write this.

Is it a mindset thing? Maybe. Could CMSs do more to help the former type of person? Undoubtedly. Would web designers then be out of a job. Well…

giz · 2014-04-08 01:18:11

Hah. I know what you mean. I get “its so logical” and “you’re gonna have to talk me through it again” from both n00bs and experienced web users alike.

We at the sharp end know it’s because there’s a truckload more going on behind the scenes

Go to any web-page text with links and formatting, and copy-paste it into your Medium story. Formatting and functionality is still there, including links, link-titles, lists etc. Headings get stripped out…

Slick.

philwareham · 2014-04-08 07:14:01

Medium is just a blogging platform though, which means it can focus in on article writing and nothing else. We don’t have that luxury. The interface is real nice though and Teehan+Lax (who make Medium) are probably my favourite design agency.

Ghost is also worth trying. Yeah they over promised on Kickstarter (I was a backer) but there are some good UI ideas there.

springworks · 2014-04-08 08:46:37

Bloke wrote #280125:

Interesting side note on this topis: one of my colleagues wanted a website for one of the products we sell. He installed WordPress because he’d heard of it, downloaded and installed a theme, and then hit a roadblock. “Why doesn’t the site look like the theme preview screenshot”? was the first question. Then, after some frustrated mouse clicks and sighs, “Why is making websites so hard? I just want this description here alongside this image. I should be able to drag it from my desktop and it should appear there” (pointing at the screen).

I was kind of internally rolling my eyes, but he had a point. In this day of touch, swipe, play, why is the barrier for website creation so high? We at the sharp end know it’s because there’s a truckload more going on behind the scenes and there’s more to design than point ‘n’ tap. But to the novice who can muck around in Fireworks, it’s frustrating.

Of course, he gave up and I was drafted in to try to get the website at least working. For my first foray into WordPress for over 8 years, overall I found the interface bafflingly convoluted, though one or two things were very nice ideas I’d love to port to Txp.

Conversely, in a couple of days of sporadic e-mail exchanges across timezones (and some sprinkled adi_notes goodness), I’ve helped a 72-year-old grandmother with a print background grasp how to create and manage content in Textpattern, and she’s tinkering and experimenting with pages and stylesheets to lay out her website as I write this.

Is it a mindset thing? Maybe. Could CMSs do more to help the former type of person? Undoubtedly. Would web designers then be out of a job. Well…

It’s a very interesting point. A lot of people conflate “web design” with “content management”, which is why there are a lot of people calling themselves web designers who are just forcing people’s content into off-the-shelf WordPress themes without doing any actual designing themselves.

There have always been visual web design tools around (Dreamweaver, Freeway, etc.) but they fell out of fashion with the rise of the web standards movement and hand coding as the code that the visual tools produced was horribly inefficient and bloated.

Now there seems to be a second wave of visual tools coming. Some, like Macaw, promise much greater control of the code produced and seem to be doing a good job of writing efficient, clean code.

Others, like Sparkle (Mac only, in beta) seem to be slipping back into the old ways of bloated, inefficient code. View source on their site and it reveals that they have a long way to go to match the quality of Macaw’s code generation.

Of course, there’s no concept of “content management” in apps like Macaw and Sparkle.

Squarespace (from my brief explorations) seems to make a good attempt at bringing together the two disciplines of web design and content management.

In terms of modular content management, I think ExpressionEngine and CraftCMS (and possibly Perch) have a strong offering, in that they approach the content model for each section of a site as a blank canvas that can be modelled using an unlimited choice of custom content fields (text fields, text areas, checkboxes, radio buttons, select menus, images, files, etc.), relationships (to entries in other site sections) and extendable tables (grids or matrices of other custom fields custom fields).

I think this is the way to go for a modern CMS to remain relevant in a world where content often needs to be marked up in a more nuanced or fine-grained way (schemas and microformats) or repurposed in various ways for different applications.

philwareham · 2014-04-08 09:23:56

I think we need to make the distinction between modular content and modular templates. Personally modular templates (as detailed in the OP article) that clients can move about to build web pages are of zero interest to me, but modular content is definitely of interest.

There will always be people striving for a drag/drop way of building websites. Short answer is it’ll never happen in any totally satisfactory way. Dreamweaver, GoLive, Freeway all attempted it and failed miserably – and that was back when sites were a lot more simple and client expectations were less.

springworks wrote #280132:

ExpressionEngine and CraftCMS (and possibly Perch) have a strong offering

I agree EE has a very good content model. None of those CMSes are free or open source though :) Perch is probably the closest to Textpattern of the three, as Drew McLellan was originally an avid Textpattern evangelist.

planeth · 2014-04-08 19:53:08

giz wrote #280110:

Sounds great (from the odd snippets I’ve read in the dev thread).

Together with something like plh_frontEdit I’d be set!

In fact, i am waiting for all the bells and whistle and ponys of custom fields to go on with the dev of this plugin …

lozmatic · 2014-05-02 06:19:00

In my experience, typically working in Marketing / Comms, unless authors are experiened Web Editors additional flexibility is a big risk: styles are messed up, the weigh of content blocks is not particularly well balanced, and too much redundant stuff is published. More restricted templates help mitigate this.

That said, I fully subscribe to the idea of modular content, but only as building blocks for templates. So content authors can select a template that most closely matches their requirements as opposed to filling in a blank canvas. And I would leave it to the CMS admin – the IA expert – to build and tweak templates (working closely with the authors to find the best solution).

To a certain degree, and successfully at that, I’ve used glz_custom_fields and bot_write_tab_customize in Textpattern.

philwareham · 2014-05-02 06:54:04

Core implementation of features found in glz_custom_fields and bot_write_tab_customize are exactly what we are intending – albeit implemented in the best way we can.

Obviously there will need to be permission levels set on who can build these fields into an editor page.

maniqui · 2014-05-31 03:59:54

I’ve been thinking about a way to approach so-called “modular content” in Textpattern with current (and upcoming-in-the-near-future) features and the help of one or two existing, simple plugins.

At some point, to me, the idea of modular content seems to boils down to a few things:

having the ability to split & store your content in smaller, reusable, sortable, configurable chunks of content,
having the ability of creating and mixing structured/constrained and unstructured/free content,
having the ability of re-using these chunk of contents across different pages and channels.

The following idea is just a “proof-of-concept” coming off the top of my head, ideas that I haven’t yet find the time to try on a Textpattern installation.

Basically the idea is:

you store contents in both built-in fields (title, body, excerpt, article_image) & custom fields. These fields are of input type text, or, in the future, textarea type.These fields can hold whatever: text, comma-separated values, URLs, numbers, video embed codes, etc.
then, there is an extra custom field named, for example, fields_order, which stores the comma-separated names of the custom fields, in the desired output order. For example: title, some_custom_field, body, article_image, another_custom_field.
if the fields_order custom field is used, then, on the article page, the fields are output in the specified order.
if the fields_order custom field is empty, then, on the article page, the fields are output in some default order.

How it works

1 Every built-in field & custom field has its own little template (stored in a Textpattern form) with all the templating/boilerplate code: HTML, Textpattern tags, etc. You can think of these forms as our “modules” to create our “modular content”.
1.1. The form is named after the bult-in field name or the custom field name, ie. if the custom field is named video_embed_code, the form is named video_embed_code. If the built-in field is body, the form is named body.

// Example of a form named "video_embed_code", for outputting the custom field named after it
<txp:custom_field name="video_embed_code" />

// Example of a form named "gallery_images", for outputting the custom field named after it
// Here, your code for a cool gallery or slideshow or whatever, 
// crafted using some "complex" HTML and iterating over a list of images ids
<div class="cool-embeded-gallery">
<txp:images id='<txp:custom_field name="gallery_images" />'>
...
</txp:images>
</div>

// Example of a form named "body", for outputting the built-in field "body"
<txp:body />

2. On your page template, inside an article context (individual or list), you test if the fields_order custom field has any value (or, else, it’s empty).
2.1. if the fields_order custom field holds some value, then, using a plugin that let you iterate over fields (like rah_repeat or smd_each), you iterate over the comma-separated value of the fields_order custom field.
2.2. In each iteration, you feed the currently iterated value to <txp:output_form form="{current_value}" />.

// Example of a page template
<txp:article>

  <txp:if_custom_field name="fields_order">
    // The user specified some order for outputting the fields

    // We iterate over the specified fields
    <txp:smd_each include="fields_order">
       <txp:output_form form="{smd_var_value}" />
    </txp:smd_each>

  <txp:else />

    // We output the article fields in some default order
    <txp:output_form form="title" />
    <txp:output_form form="gallery_images" />
    <txp:output_form form="body" />
    <txp:output_form form="video_embed_code" />

    // etc

  </txp:if_custom_field>

</txp:article>

As you can see, this way enables you (or the end-user for the Textpattern CMS) to have some control —on per-article basis— over the order in which the built-in fields and custom fields are sorted in the output.
This basic example opens up some editorial possibilities and freedoms for implementing modular content without the need to sacrifice structured rich content and without the need to resort to WYSIWYG and/or drag-and-drop interfaces and/or new custom fields created on the fly.

And this could be just a beginning. You could then start to use chunks (ie. a “module”) of some article inside another article. A few ways to do that: one could be using txp:article_custom inside some textarea field on a new article, like this:

// Content of body field
Lorem ipsum dolor sit amet, consectetur adipisicing elit (...)

<txp:article_custom id="123"><txp:output_form form="gallery_images" /></txp:article_custom>
// Or even <txp:article_custom id="123" form="gallery_images" />

(...) sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Another way could be using some “structured” format for the comma-separated strings used in fields_order. For example: title, gallery_image:42, video_embed, body. This would call all the fields for this articles, except for the gallery_image field, for which it will fetch the gallery image corresponding to article with id=42. This would require some conditional testing and processing of the string gallery:42 on the corresponding custom field form. I’ll leave up that as an exercise for the reader. :P

Some may find this solution a bit cumbersome, and it may be (particularly for those end-users that prefer more GUI-based solutions, WYIWYG/click-form-intensive/drag-and-drop sorting for “module content”.
But, well, I tend to look for textpatternish ways of attacking problems. :)

etc · 2014-05-31 10:56:12

Hi Julián,

while your approach is very flexible, there is a point I dislike: every <txp:output_form /> means a db query… Except edge cases, you won’t need per-article customization, so override_form should suffice.

maverick · 2014-06-03 19:27:36

Thinking aloud.

It seems to me that there are so many tasks being attempted at once, it gets rather confusing, and at times those different goals end up at odds with one another.

Textpattern’s initial draw for me was it’s two strengths: the UI was designed to make quick work of writing, and the publishing felt xhmtl familiar.

Abstract that a bit. There are three tasks taking place: Content input, Content Management, Content Output.

Textpattern by design was simplistic in content management. It was designed for a basic group of users to publish basic articles. It had a limited data model with rudimentary tools for managing existing content. Database-wise, it was simple. The writer-centric UI addressed input, txp: tags address publishing to a specific medium (the web). The latter two were the focus of its abilities.

The more sophisticated CMS software entries, and the various feature requests for Textpattern have tended to push for greater capabilities and greater flexibility in all three areas, along with a UI for each that is simple yet grants access to those greater capabilities.

So now we need a way to create data models, and a corresponding UI, a way to enter data, and a corresponding UI, a way to manage data, and a corresponding UI, a way to manipulate data, and a corresponding UI, and multiple ways to publish the data, and corresponding UIXs.

Our discussions revolve around the features and abilities of other CMSes, almost all of which use an old paradigm at their core: publishing for the web. Yet if we are honest, the only part of Textpattern that is specifically website publishing is the txp tags. A wonderful way to create templates for publishing to the web, but perhaps an increasingly smaller part of the overall picture of what is being demanded.

Perhaps instead of, or at least in addition to, ExpressionEngine, and Perch and such, we might want to look at the older, and truer content management systems: database programs like FileMaker and 4D and so forth.

Consider: Filemaker 13 provides a slick input for creating data models with relationships. It provides for both data entry and data display – whether browsing records on screen or printing a report or even publishing to the web or syncing with remote databases.

It seems to me that Filemaker and applications like it are doing much of what we and other CMS projects are talking about – because content management at its core is about database creation, manipulation, and management.

Of course, 4D and Filemaker are both CMS and database combined.

Are we not really seeking to find a way to create a php/msql software that does what a traditional desktop database application does? One that speaks “web” natively? So why don’t we reference these apps more in our discussions?

Okay. Done with thinking aloud. I’ll return to the quiet of my rock :D

Last edited by maverick (2014-06-03 19:29:11)

Textpattern CMS

Textpattern CMS support forum

#13 2014-04-08 00:01:22

Re: Modular Content

giz wrote #280123:

#14 2014-04-08 00:19:33

Re: Modular Content

#15 2014-04-08 01:18:11

Re: Modular Content

#16 2014-04-08 07:14:01

Re: Modular Content

#17 2014-04-08 08:46:37

Re: Modular Content

Bloke wrote #280125:

#18 2014-04-08 09:23:56

Re: Modular Content

springworks wrote #280132:

#19 2014-04-08 19:53:08

Re: Modular Content

giz wrote #280110:

#20 2014-05-02 06:19:00

Re: Modular Content

#21 2014-05-02 06:54:04

Re: Modular Content

#22 2014-05-31 03:59:54

Re: Modular Content

#23 2014-05-31 10:56:12

Re: Modular Content

#24 2014-06-03 19:27:36

Re: Modular Content

Board footer