Improving TXP Image Management

jameslomax · 2006-05-10 14:45:37

OK, well this is getting a bit technical for me. Just want to mention a few things:

Use-ability: some major work is going into this, and it really deserves some good use-ability design. Not to suit all the coders and technical developers here but for users, like myself :-)

There’s still the option of having an ‘image insert’ panel as part of the default article page, something like bas_img_selector but more developed. In-depth navigation could be left for a separate tabbed page, as has already been built. In practice, you don’t often need to navigate your entire image collection – this is important. Insert-image and ‘browse-all-of-them’ are, in reality, two different needs.
If this project is for the needs of image-heavy sites, photographers etc, like myself, then an admin page insert panel is just as important as the text area.

SVN developments will probably happen eventually, and maybe within six months this new code will be part of the txp core – great! However, if there’s a plug in available now – which there is – it would be great if this is developed just a little more, especially for uploading.

Remember – that single column design is a no-no :-)

Last edited by jameslomax (2006-05-10 14:58:48)

marios · 2006-05-10 22:46:29

Now , again, I didn’t read all the threads, (some of them, as they add up).

Once again I am stumbling on a very basic problem for TXP image handling from the practical side.

<h1> Short explanation: </h1>
When authoring on article pages, it is sometimes the case, that you don’t do this actually straight in from the TXP default textarea, but rather use a third party text-editor for that, since that’s the only way to productively author a page using custom html.
(That is for various reasons, not directly related to image-handling, mostly those are missing features like integrated spell check,problems with textile handling and validation, and missing integration features for third party applications that would allow you to author article pages on a more wider scope, etc.)

That might not be the case for the majority of the users, but still seems important enough to find it worthwhile to mention it here.

To make it short, let’s take a very simple basic example.
Let’s say, you write a technical article about how to set up a specific Networking device.
To deploy the workflow mentioned above, you would open your external editor, import some photos along, may be make some screen shots and collect some code snippets on the way.
Naturally, since I’m authoring right from the outside, the workflow for most users would be as follows: I’d rename my Images,let them go into a category folder (that could match the article title may be), upload them to the Server to the Images folder, and reference them right away from the editor, while I author along and once done cut and paste everything in the textarea and publish.
Problem there the ID renaming thing, because, the images could still be inserted automatically to the database until now through the plugin.
It just didn’t feel natural to me ,to go into the image handling feature and insert those after I have published my article.

So, to make it a little shorter, how difficult would it be, to let TXP recognize your image names right from the database( so you can have your custom file naming convention), and let it warn you in those cases it find’s double instances, and still have the e.g. t=thumb, l=large,parameter prepend option in the file name.
when you upload images to the server, there could still be some kind of auto rename feature for double instances, that could be presented to the User right after accessing the back-ends image tab along with a warning message, for example:

<strong>WARNING</strong>
TXP found double instances of file names for the same image files, what would you like to do, bla bla bla….

In the meanwhile TXP would still insert those instances in the database, but put a special flag on them or temporary alter their file name to something else maybe.

I’m not sure, if this excursion was a little to long for such a single matter, but I think it’s mostly those basic simple things that matter, instead of having zillions of features for image handling, that I doubt would ever be used by every User.

regards, marios

Last edited by marios (2006-05-10 22:48:05)

jameslomax · 2006-05-11 08:58:46

With regard to the more specific themes and ideas of this thread, as they pertain to the code currently being developed, the above from Marios (partly) highlights the following. The workflow problem where you have you go into the image tab, then upload an image, generate a thumbnail and save it in a cateogry, then return to the article page and find it again, to then insert in the article.

Basically, the two components of this – image management and article posting – are not integrated. The best interface support for image-based sites is to integrate these two components; my suggestion is a panel like bas_image_selector, but more developed.

You still need a comprehensive navigation page, but that’s not the whole solution to efficient workflow.

squaredeye · 2006-05-11 13:04:39

Marios,
I think these are good questions you raise.
I’m not totally sure how to address them, except to say that the “issue” or “problem” you raise can be addressed in the write up and see what the devs want to do with it? Alex has started on the write up, and if I have some time this weekend I will add to it. Its hard to know whether its better to take huge steps or giant leaps, but I do know that the devs will be concerned with backward compatability as usual (and for good reason I think), and so without knowing what those parameters are its hard to say how drastic a change to the current conventions are reasonable?

Any coders care to weigh in on that?

Matthew

guiguibonbon · 2006-05-11 15:29:42

The proposition for a more powerfull image tag already adresses this issue with a image_name attribute, no? Or maybe I didn’t really understand your problem, Marios.

Now, guys, I thought about something else, wouldn’t a “live search” feature be interesting in the image-browser? Rather than using radio-buttons for categories, names, ids and everything?

Last edited by guiguibonbon (2006-05-11 15:31:27)

hakjoon · 2006-05-11 15:44:04

The image_name attribute was intended to reference the image name in TXP not the filename, since TXP does not maintain filenames. However I think by default the filename is placed as the image name on import, if not that could be adjusted as part of the image import process.

There is no uniqueness enforcement for image names in TXP right now (that I know of) so that’s something that needs to be thought about in order to fully use image_name as a selection option, at the very least predictable behaviors in case of conflict should be determined. Of course a uniqueness check could be done on import similar to how url-title duplicates are handled.

I like the live search idea a lot.

guiguibonbon · 2006-05-11 16:44:48

Well yes, that’s what I meant. Is there no uniqueness check for the images at the moment? Then what good are those image names anyway? Good thing you like the live search, I think Ajax is something that will become hard to avoid. Thought of something else concerning image exploration : it would be a nice thing if the thumbnails displayed could be resized at a maximum width, for I tend to use large thumbnails (460px), so things get quite messy. The WP-way is one solution, or an overflow:hidden div around the images.

I also looked a little closer at that advanced txp:image suggestion, and there are a few points that strike me:

how is the custom-height and custom-width supposed to work? Wouldn’t those rappidly become a web-space disaster (creating many unused thumbs) ?
all the show_something attributes : why would anyone ever not want to show the width/height, or the alt, or the title? And if ever that would occur, wouldn’t a form give enough freedom? This is just in a concern of keeping things simple.

hakjoon · 2006-05-11 18:55:09

guiguibonbon wrote:

how is the custom-height and custom-width supposed to work? Wouldn’t those rappidly become a web-space disaster (creating many unused thumbs) ?

Web space could be a big issue there. I thought of it more as an image cache, so instead of creating x number of thumbnails with different sizes like what your mockup showed (this was the original idea BTW) you would be able to specify what size you wanted your thumbnail when you actually use it, the thumb would be generated on the fly and cached. Essentially you would only create thumbnails in sizes you actually use, and you could “clear thumbnail cache” to remove any ones generated during testing or something.

This would eliminate the situation when you need a variant size for only specific instances. The main goal was to offer different sizes other then the one thumbnail size. How it’s managed is open to discussion, I think your proposal is equally if not more workable, although I could see maybe needing more then 3 sizes. EZ-publish automagically created large,medium, and small thumbs but it also allowed you specify custom sizes. I have to recheck how that worked.

This was just one idea that came out of a different discussion at one point.

all the show_something attributes : why would anyone ever not want to show the width/height, or the alt, or the title? And if ever that would occur, wouldn’t a form give enough freedom? This is just in a concern of keeping things simple.

This is just what upm_image offers, and it is currently the closest thing to this that is out there. I think it does that though because it doesn’t force you into a form. If we made <txp:image> have a default form that is editable like <txp:article> and <txp:linklist> we could probably get rid of them. I think they are kind of unnecessary but I’m sure all those that use it would disagree with me.

Definitely don’t take anything in the wiki page as set in stone. It was put up there to generate exactly these types of questions so we can figure out what we need and try to narrow it down to a concrete set of requirements instead of everyone re-phrasing things all the time.

Last edited by hakjoon (2006-05-11 18:55:43)

firago · 2006-05-14 20:57:41

I use photos in my

* css stylesheet * personal blog to help prove a point

These are what I think are limitations in the current TXP system of handling/posting images

* that you have to use the numbers that TXP assigns to the images, instead of the title you choose for the image

I would like to see the following functionality

* It would be great if TXP could allow you to call to the images as the title you make for them, not the number TXP assigns

I would like to help think through the implications of such functionality in this way

* round of drinks for people who give a crap

jameslomax · 2006-05-15 18:59:46

This looks an interesting Wordpress project

squaredeye · 2006-05-15 19:05:44

jameslomax,

Great plugin. I think it would be worth asking folks what they think about it.
Well, how about it. What do people see as the strengths and weaknesses of this plugin?

Thx.

M

Skubidu · 2006-05-15 19:23:47

This really looks interesting, James.

One update concerning nhn_image_organizer : I’m working on some static HTML pages to simulate the possible features of the plugin. But the development is going very slowly because I’m still working on my final thesis at university…

Nils

squaredeye · 2006-05-15 19:27:02

Nils,
Let us know how we can help, and focus on your studies! Not on we the sqeeky wheel. Blessings as you write.

M

Skubidu · 2006-05-15 20:59:04

I’m working on some static HTML pages to simulate the possible features of the plugin.

Just as a teaser:

There are now two different views that you can switch by clicking one of the icons in the upper right corner:

a list view
and a thumb view

The screenshot shows the second one ;o)

Nils

jameslomax · 2006-05-15 22:43:46

What I like about the WP plug in is the way image management is beautifully integrated. There’s no seperated click-this-tab-to-upload-then-click-this-tab-to-save-then-click-this-tab-to-insert workflow; something I’ve referred to before re. the difference between image navigation and image insertion into articles: two different functions that need to be integrated; my suggestion was a more sophisticated bas_image_selector

Also, I like the option to upload either a) one image or b) and entire directory of images. I guess the next step, for txp, is how those multiple images are assigned an identity so they can actually be used. Is this an inherent weakness of txp behaviour? – its certainly a weakness of its image management.

Last edited by jameslomax (2006-05-15 22:49:01)

Textpattern CMS

Textpattern CMS support forum

#166 2006-05-10 14:45:37

Re: Improving TXP Image Management

#167 2006-05-10 22:46:29

Re: Improving TXP Image Management

#168 2006-05-11 08:58:46

Re: Improving TXP Image Management

#169 2006-05-11 13:04:39

Re: Improving TXP Image Management

#170 2006-05-11 15:29:42

Re: Improving TXP Image Management

#171 2006-05-11 15:44:04

Re: Improving TXP Image Management

#172 2006-05-11 16:44:48

Re: Improving TXP Image Management

#173 2006-05-11 18:55:09

Re: Improving TXP Image Management

#174 2006-05-14 20:57:41

Re: Improving TXP Image Management

#175 2006-05-15 18:59:46

Re: Improving TXP Image Management

#176 2006-05-15 19:05:44

Re: Improving TXP Image Management

#177 2006-05-15 19:23:47

Re: Improving TXP Image Management

#178 2006-05-15 19:27:02

Re: Improving TXP Image Management

#179 2006-05-15 20:59:04

Re: Improving TXP Image Management

#180 2006-05-15 22:43:46

Re: Improving TXP Image Management

Board footer