Improving TXP Image Management

squaredeye · 2006-11-15 20:45:37

good thoughts Hak.

A more extensive attachment scheme might be worth thinking about?

files, file categories, images, image categories

And as, Hak described, perhaps there is a way to do that so that you can choose
your image/category/file/category and then choose the display type based on a form? (from a set of forms?)

M

mrdale · 2006-11-16 04:45:07

Yeah, I’ve always thought that the clear deliniation between images and articles, but the ability to associate one with the other, is a very good one. I just think that the display tag should work a lot more like the image tag.

feragnoli · 2006-11-16 12:38:30

mmm… ok.
well creating image cats after the article name is a hak for such it was in the first place. But what I meant to say is that in terms of use, for a user (not somebody used to blogging/web publishing/etc), it’s just more intuitive that the category of images he wants to put in his article be called his-article-about-grandpa rather than article-2365.

And that’s why I had modified rss-thumbpop in the first place.

hak wrote: I feel like article -> Image relationships are exactly what the article-image field are for. It’s exactly that, this article is related to these images. Articles and images don’t necessarily have any relationship. I can have images that exist solely in an image gallery context without being attached to any articles.

That is all very true, but… dunno… maybe it’s me, yet I would say that the way the article-image field works now… sucks.
It just does not work having to write numbers or urls in there (and poppers that paste such numbers in the field are just a hack too).
In general, I think that we should try to understand not only the identity of our elements (eg. images, now) but that of our (possible) actions too.
That means that while article and images stay different and separated elements the act of publishing them on the web stays one (articles are text, images are… images, paste a video there too and you’ll have the holy trinity of the media). You should therefore be able to exercise your publishing function from within the write tab no matter what you’ll be publishing.
The fact that you might create image gallery pages only working with sections and categories and without publishing one single article as such on those pages implies that you’ll be messing around with the publishing structure of the site. That’s something my users wouldn’t want, would yours?

Ez-publish has this feature called related objects that let’s you attach objects to that article. The display is different depending on the view or object, so you would in essence attach the image category to the article and then decide how that attached object should render (mini gallery, link to gallery). This gives you ultimate flexibility because the category will still be attached to the article even if titles or names change.

That is indeed a very interesting option, but how far away?

Last edited by feragnoli (2006-11-16 12:48:14)

hakjoon · 2006-11-16 13:36:59

feragnoli wrote:
it’s just more intuitive that the category of images he wants to put in his article be called his-article-about-grandpa rather than article-2365.

Agreed. And this is a great way to work around the current limitations of teh system. I just like to think twice before creating behavior to ease certain behavior that comes out of current limitations. I rather work to reduce the limitations.

Think of what the problem is not how to enable the process you came up to solve it.

That is all very true, but… dunno… maybe it’s me, yet I would say that the way the article-image field works now… sucks.
It just does not work having to write numbers or urls in there (and poppers that paste such numbers in the field are just a hack too).

Agree. This could be done in better ways that better hide the numbers and urls from the user.

The fact that you might create image gallery pages only working with sections and categories and without publishing one single article as such on those pages implies that you’ll be messing around with the publishing structure of the site. That’s something my users wouldn’t want, would yours?

Depends on what type of site you are working in. For a portofolio site you could pretty much spend all your time uploading images into categories. Once the basic pages and forms are layed out this culd mena yoiu never have to actually go to the write tab.

hak wrote Ez-publish has this feature called related objects that let’s you attach objects to that article. The display is different depending on the view or object, so you would in essence attach the image category to the article and then decide how that attached object should render (mini gallery, link to gallery). This gives you ultimate flexibility because the category will still be attached to the article even if titles or names change.

That is indeed a very interesting option, but how far away?

well some of the purpose of this thread is to come up with the best ideas. There’s not really a timeline. It’s a matter of something becoming clear enough that someone picks it up.

feragnoli · 2006-11-16 15:58:24

hakjoon I hope my comment did not come across as… aggressive, ironic or something. If it did, I apologize.

Anyway, what I wanted to say is that indeed it is about reducing the limitations but there are certain, simple things in Textpattern that are fine just the way they are: plain and simple.

For instance, when you say:

Depends on what type of site you are working in. For a portofolio site you could pretty much spend all your time uploading images into categories. Once the basic pages and forms are layed out this culd mena yoiu never have to actually go to the write tab.

You are defenetely right but at the same time I think my users (busy with the making of their portfolio) would argue why there’s a write tab at all and I wonder what that tab is for? (let’s consider a portfolio which requires no text publishing…). That would mean we would still be in the position of having to hide part of the system or defining weird guidelines for the users (“… the only thing you have to do is this and that and not that…”) instead of having a simple, intuitive system.

The point I wanted to stress was that, at the moment, some aspects (steps) of the same functions (or actions, like: publishing) are spread around in different tabs and I think they should be brought back to proper locations.
So, the write tab (which by now maybe should be regarded as publish tab) should do all the publishing while, in my opinion, the images, files, etc tabs should all be about file managing.

mrdale · 2006-11-16 16:04:29

feragnoli wrote:

The fact that you might create image gallery pages only working with sections and categories and without publishing one single article as such on those pages implies that you’ll be messing around with the publishing structure of the site. That’s something my users wouldn’t want, would yours?

Actually, I create sites so that allow my clients to create image galleries with captions, solely through the image tab. They can add images, captions, and add a subcategory of the “gallery” parent category, without ever touching the structure tab.

They seem to like it, and have never asked me for anything simpler.

hakjoon · 2006-11-16 17:57:07

feragnoli wrote:
hakjoon I hope my comment did not come across as… aggressive, ironic or something. If it did, I apologize.

Absolutely not. I didn’t want you to think that I was just dismissing your thoughts and ideas which I believe are very, very valid.

It’s that sometimes it takes stepping back from the solution and thinking of the problem in order to develop the best solution. That was all I was trying to do.

I apologize if you thought my tone was defensive, it was not meant that way at all.

igner · 2006-11-16 20:22:56

Well, I think the important thing to stress in that case is that this is *Text*pattern we’re talking about. Above all else, it’s about the words¹. It just so happens that it’s evolved quite nicely into a fairly flexible, fast (yet lightweight) CMS.

I believe wholeheartedly that image management is critical to TXP’s growth (though the 4.0.4 release does make working in the image tab far easier, and Mary’s upm_image_popper plugin makes a world of difference from a composition standpoint). But something like gallery / portfolio publication – my gut feeling is for the users who are managing a portfolio site with no articles, then there’s space for a custom image management interface that ties back to the Textpattern database. Then you as the site developer / manager spend time in the Textpattern interface, but your clients get a very streamlined, targeted interface.

But there’s a cost there in terms of development time, costs which may or may not be passed on back to the client. Granted, that takes away from the point of using TXP to build the site in the first place (particularly the rapid deployment concept) but only the first time. Yes, I realize that it’s not trivial to build such an interface, but I suspect it’d be easier to build an interface outside the constraints of the current Textpattern admin interface, and simply borrow / reuse code as needed.

I guess bottom line here is that I see the requests to “hide everything but the image tab, and then modify how the image tab handles categorization?” as the wrong question to ask. The question I think should be asked is “how do I replicate the image tab functionality in a stand-alone interface?”

Kind of a rambling response – but I think sometimes folks get a little carried away trying to make the tool they have work, rather than consider another tool.

¹ If there’s any question about where Dean’s heart was when he started writing TxP, then read this article over at ALA.

feragnoli · 2006-11-17 10:49:14

Dunno, I think Textpattern is flexible enough to handle the whole publishing process no matter what the object of this publishing is. What was the original goal of Textpattern shouldn’t really matter, should it..?
The custom interface for image management… you could do that but wouldn’t it be… healthier to just have one interface simple and intuitive enough in its nature not to require any customization?

igner · 2006-11-17 14:37:16

feragnoli wrote:

Dunno, I think Textpattern is flexible enough to handle the whole publishing process no matter what the object of this publishing is. What was the original goal of Textpattern shouldn’t really matter, should it..?

I think for some of us, the answer is actually YES it should matter. But hey, I could be wrong on that front. Wouldn’t be the first time, nor will it be the last.

feragnoli wrote:

The custom interface for image management… you could do that but wouldn’t it be… healthier to just have one interface simple and intuitive enough in its nature not to require any customization?

Again – a subjective matter. While I think there’s room for improvement in some facets of the admin interface, on the whole it’s fairly clean and usable, and to me fairly intuitive.

My comments on the custom interface were something of a knee-jerk reaction, I’ll admit. However, the same discussion has gone on for quite some time, with little resolution; but the general sentiment remains. If all your clients want/need is image management functionality, then I’m not sure that it makes a ton of sense to try and change the way TXP behaves; why not focus on making an interface that does what you want. And if you’re so inclined, open it back up to the community.

For a bit more context, my number one concern for image management is how to streamline the use of images in the context of TXP as a publishing system; in other words, how do we make it more feasible to work with images in the context of publishing articles. The secondary concern is how to make the image tab more manageable in general. But it’s secondary to that primary concern.

Do I think some sort of gallery / portfolio module would make a great addition to TXP? Absolutely. Do I think that should take precedence over making it easier to include images in articles being published? Absolutely not.

Mike Montgomery · 2007-01-09 16:07:24

mrdale wrote:

Actually, I create sites so that allow my clients to create image galleries with captions, solely through the image tab. They can add images, captions, and add a subcategory of the “gallery” parent category, without ever touching the structure tab.
They seem to like it, and have never asked me for anything simpler.

How exactly do you do that?

I’m familiar with wet_for_each_image and upm_image, and have used rss_thumbpop before…

Specifically, I understand how they “add a subcategory of the ‘gallery’ parent category, without ever touching the structure tab”,
but how do you set up the structure to present those (currently unknown) subcategories?

Textpattern CMS

Textpattern CMS support forum

#289 2006-11-15 20:45:37

Re: Improving TXP Image Management

#290 2006-11-16 04:45:07

Re: Improving TXP Image Management

#291 2006-11-16 12:38:30

Re: Improving TXP Image Management

#292 2006-11-16 13:36:59

Re: Improving TXP Image Management

#293 2006-11-16 15:58:24

Re: Improving TXP Image Management

#294 2006-11-16 16:04:29

Re: Improving TXP Image Management

#295 2006-11-16 17:57:07

Re: Improving TXP Image Management

#296 2006-11-16 20:22:56

Re: Improving TXP Image Management

#297 2006-11-17 10:49:14

Re: Improving TXP Image Management

#298 2006-11-17 14:37:16

Re: Improving TXP Image Management

#299 2007-01-09 16:07:24

Re: Improving TXP Image Management

Board footer