The direction of Textpattern 5

Dragondz · 2011-01-23 08:53:44

Hi

Happy to see that some huge change are coming, i am happy with txp now but something dont evolve will die!

If I can add my 2 cents about features to add: a better authorisation process ( ability to restrict user to some sections or categories or something like this).

I tried to see the framework but havent found any documentation about it and how it works!

hcgtv · 2011-01-23 13:18:39

maniqui wrote:

Lot of things could change in TXP5 paradigm, making current concepts/workflow to become obsolete.

Over the years we’ve seen web developers defect to other systems, most notably Expression Engine. So if this paradigm shift is being done to stop loyal web developers from defecting, then just go the EE route and start charging for Textpattern 5.

Nothing in the last 5 years has been done to garner more users, whether it be in making the code base easier for the newbie or in promoting this niche of a system. So obviously the focus is not on someone who just wants to put up a blog or a simple site, it’s more towards the web developer who uses Textpattern as one of the many tools in his or her arsenal. But from what we’ve seen in the past, this does not bring in much money, now does it?

2011 is a perfect year to go after more users, by 2012, they’ll be so much noise in the atmosphere that any project announcements will be drowned out. Now’s the perfect time to strike, newbie tweaks to the core coupled with guerrilla marketing, and we can see a large influx of users. Then get them excited about the new roadmap to TXP5, which will keep the momentum going.

No matter how much you love to code, there comes a time where you want to see the fruits of your labor be rewarded, whether it be from recognition (more users), or from money flowing in from services or donations. So if you like to code in relative anonymity, then by all means, keep the status quo.

thebombsite · 2011-01-23 18:02:31

Plus, considering how many web developers/designers use this application for free, it’s surprising how few emails a get asking if I would put someone’s new theme up on Textgarden, whether it’s free or not. I could probably count them, for a year, on both hands.

mrdale · 2011-01-25 15:36:21

All worthy ideas/discussions and reason for a lot of optimism for the futrue of txp.

Let’s just hope that the ratio of spectators (includes self):devs is high enough to make all this a reality.

artagesw wrote:

Escher has all of the above (well, not nested content types). Read into that what you may.

to tell you the GH truth, I’m a creature of habit and momentum, and I could never quite grok the Escher paradigm, which is more of a statement about me than about your excellent work. I am holding out hope that TXP 5’s differentiation from 4.x will be functionally dramatic but conceptually very similar.

Last edited by mrdale (2011-01-25 15:36:43)

vurt · 2011-01-27 14:10:44

A brief and surely incomplete wishlist:

- integrated database management, ala rss_admin_db_manager

- better search parsing, to include sections, pages, etc.

- version control, ala rah_post_versions

- front side theming, ala WP (frankly I think this is what made WP what it is today.)

- multiple image support for articles (and it needs to be more intuitive for clients. I couldn’t live without hak_article_image, but you have to know how to use it.)

- better storage structure for images (I’m scared of that one giant folder. Should I be?)

- WWCD (What would a client do?)

And, congrats to the dev team for their ambition and ongoing commitment to txp.

jsoo · 2011-01-27 14:56:15

vurt, thanks for the list. All good items.

vurt wrote:

- integrated database management, ala rss_admin_db_manager

I don’t see this as a core function. For one thing, I expect Txp5 to allow databases other than MySQL. To do this well, even for one DB type, is a big job, and I think well beyond the scope of what core Txp should do.

- better search parsing, to include sections, pages, etc.

a la smd_where_used? I agree.

- version control, ala rah_post_versions

See my remarks on DB management.

- front side theming, ala WP (frankly I think this is what made WP what it is today.)

Lots of ways to read the parenthetical comment :)
But yes, this is a must-have.

- multiple image support for articles (and it needs to be more intuitive for clients. I couldn’t live without hak_article_image, but you have to know how to use it.)

I like the idea. I can see different ways to implement this. One would be as now, allow a comma-separated list of images, but then modify article_image to go through the list if you call it multiple times. That is, the first article_image tag gets the first image in the list, the next article_image tag gets the second image, etc. You can do this now with images and offset, but that’s cumbersome.

Another idea is to allow article_image to call custom fields by name, so that you can create custom fields for specific image roles within articles. Of course, you could do that now with image by setting id to the custom_field value, but that’s cumbersome.

- better storage structure for images (I’m scared of that one giant folder. Should I be?)

At the least, there is strong support for separating content images from design images. But clearly, there’s a lot that could be done in this area.

- WWCD (What would a client do?)

Making the admin more customizable and user-friendly are important goals.

Bloke · 2011-01-27 15:24:00

jsoo wrote:

the first article_image tag gets the first image in the list, the next article_image tag gets the second image, etc.

Interesting. Not considered that approach before.

Regarding images, I still maintain that the core should support the lowest common denominator on the admin side and let plugins twist the interface to fit the ever-changing needs of clients. For example, unless it is done incredibly well, I would not like to entertain the notion of having an image picker directly on the Write tab (a link to a popup, stripped down version of the Images tab would, however, be rather handy).

If the core did it as a select list of filenames, someone would want thumbnails. If we did it as thumbnails, someone else would complain it takes up too much space. And someone else would complain that it needed to show the full size image on hover (others might want this onclick). The sheer number of configurations is overwhelming and to implement one of them as core means alienating a whole bunch of people.

The current configuration of allowing a simple list of IDs to be entered is the absolute minimum that TXP can do. It’s not ideal, but there are plugins out there that allow you to visually pick images. To my knowledge, since the introduction of TXP 4.3.0, not one plugin (umm, well perhaps redbot’s: I’ve never used it) has capitalised on the ability to completely replace the Article image field with a hidden field + a flexible uploader. jmd_img_selector was the closest I saw (ages ago).

So, while image management on the Write tab might seem attractive in core, it would need very careful consideration. I’d rather spend time making the admin side more configurable to allow plugins to easily offer this ability than to put a stick in the ground and force everyone to use something that only fits a handful of image-heavy users. Not saying it’ll never happen, but if it happens, it probably won’t be me who codes it :-)

vurt · 2011-01-27 15:54:42

For example, unless it is done incredibly well, I would not like to entertain the notion of having an image picker directly on the Write tab (a link to a popup, stripped down version of the Images tab would, however, be rather handy).

Is there a reason why you can’t have a picker that navigates to your image bank, so that you can select it from there and upload it, rather than having to memorize the image id in a separate tab? (I’m speaking strictly from a client’s viewpoint.)

This also gets back to:

front side theming, ala WP

Both of these things speak to what makes a CMS competitive with other CMSs. Front end developers need a product that they can “sell” to a client. I’ve had more that one client insist on wysiwyg for writing articles, and the image tab blows their minds (apparently for some this isn’t too difficult.)

That being said, I don’t have a problem with how it works, but some clients do.

mrdale · 2011-01-27 16:20:56

Bloke wrote:

Article image field with a hidden field + a flexible uploader. jmd_img_selector was the closest I saw (ages ago).

This is a no-brainier to be included in core. When I do demos, I show this method of association first and then show customers what it does behind the scenes. They just get it.

I agree with keeping core image control simple. In fact I think the current setup (excluding the UI implementation which is clunky) is about as straightforward as it can get. I’d just like to see a more visual image tab. One that follows a simple grid of images is far more space efficient and immediate.

Image caching, multiple image sizing, and all kinds of sexiness should be handled by tags & plugins. IMHO

Last edited by mrdale (2011-01-27 16:21:11)

maniqui · 2011-01-27 16:22:05

I was mentally writing a similar post to the one posted by Bloke.
Mine won’t have been as clear as his.
I agree with what he stated.

In general, I’m against on dumbing-down TXP.
Dumb-down TXP too much and it will become WP (the software and the audience).

The main niche of TXP is clearly defined: web developers of all ranges, newbies or experienced devs, with different set of skills. They could be mainly HTML/CSS devs, or PHP/programming freaks, and TXP fits both: they can create websites, or they can extend TXP with plugins, or both. Again, TXP is aimed to be an usable tool for web developers within all levels of knowledge, being noobs or experts, or someone in the middle (like me!).

Then, there is a secondary, minor niche of TXP users: the end-users, usually our clients/friends (non tech-saavy) or ourselves (web developers, main niche, read above). Both (they and us) like dumbed-down stuff at the end of the day, when the time to create, write & publish cool, original, beautiful content comes.

Bottom line: as I understand (and expect), the direction of TXP5 is to empower its main niche (web developers) to let them empower their secondary niche (friends/clients, that is, end-users).
It may be by creating plugins that helps to dumb-down TXP user interface (using a graphical image selector, like jmd_img_selector) or it may be by teaching them how to put a few image ids on an input field (no quantum physics nor obscure science involved).

Last edited by maniqui (2011-01-27 16:24:54)

maverick · 2011-01-27 16:23:48

vurt wrote:

the image tab blows their minds

imho, part of the issue we have is that from UI/Usability point of view, the user tends to conceptually view the write tab and the image tab as equals. Makes some sense – they are presented at the same level of our navigation hierarchy.

However, we who work w/ Txp know that the image tab is more comparable to the article tab. You have to click on an individual image to get to something comparable to the write tab. And when you get there – it isn’t anything at all comparable to the write tab.

The article and image tabs are geared towards content management. The write tab is geared more towards publishing content.

Since you are dealing with an image, the image publishing tab cannot and should not be identical. Yet even where it could be – say having two categories, or custom fields, etc. it is lacking.

I think that for an image-oriented client, they would prefer the ability to associate articles with images rather than images to articles. Which, perhaps would make it easy to associate multiple images to a single article. But doing it from an image (publishing) tab that has comparable abilities and visual design to the write tab.

*edited for clarity and grammar :) *

Just thoughts.

Last edited by maverick (2011-01-27 16:31:34)

maniqui · 2011-01-27 16:50:51

When vurt asks for

- multiple image support for articles (and it needs to be more intuitive for clients. I couldn’t live without hak_article_image, but you have to know how to use it.)

it seems to me that he’s asking for some support that is already provided by both built-in tags and plugins (like smd_gallery, upm_image, hak_article_image, soo_image and others).

Now, if he is asking for something else, more similar to what jsoo suggested, then that’s another, whole different, thing.
If so, now we are talking on a simpler way for end-users to use images in a unstructured way, inside their article body, “mixed” within the paragraphs they write. Again, that’s a whole different thing, and there are many approaches/solutions to empower end-users to do this: as jsoo suggests, it could be a tag that “consumes” the ids on article_image input field, or it could be some custom Textile block tag, or it could be common POSH, which could be even inserted by a WSYIWYG editor. I’ve a lot of ideas on how this could be done without scaring the **** out of your friends/clients that they will have to write the codez manually.
But, imho, that’s not in the the realm of what TXP should care about on its most deeper, inner cogs.

Last edited by maniqui (2011-01-27 16:51:48)

Textpattern CMS

Textpattern CMS support forum

#37 2011-01-23 08:53:44

Re: The direction of Textpattern 5

#38 2011-01-23 13:18:39

Re: The direction of Textpattern 5

#39 2011-01-23 18:02:31

Re: The direction of Textpattern 5

#40 2011-01-25 15:36:21

Re: The direction of Textpattern 5

#41 2011-01-27 14:10:44

Re: The direction of Textpattern 5

#42 2011-01-27 14:56:15

Re: The direction of Textpattern 5

#43 2011-01-27 15:24:00

Re: The direction of Textpattern 5

#44 2011-01-27 15:54:42

Re: The direction of Textpattern 5

#45 2011-01-27 16:20:56

Re: The direction of Textpattern 5

#46 2011-01-27 16:22:05

Re: The direction of Textpattern 5

#47 2011-01-27 16:23:48

Re: The direction of Textpattern 5

#48 2011-01-27 16:50:51

Re: The direction of Textpattern 5

Board footer