Images panel thoughts

Destry · 2011-08-24 16:31:17

I’m about to hand over a site to a client, and the one last thing needing worked out was adding images to articles (always a stickler for people not used to the basics of markup…even worse for Textile and Textpattern tag building concepts). The definition is for images floated left or right, and sometimes full width of the mca. The site is also HTML5 and makes use of figure and figcaption when they want to put an actual caption on something.

There’s no way to automate this entirely from the tag builder, so I’ve whittled it down to as close as I can before they have to start messing about with captions, which is documented for them. I’ve modified the tag builder (using CSS alone – Thanks for the tip, Uli!) so it shows them only the following three fields, where bold shows modifications to the label to help guide them with the specific values to enter:

Type
CSS class (use left or right)
Wrap tag (use figure)

The workflow changes a bit depending whether they want a caption or not. I

If no caption, they just use the CSS class field to put a “left” or “right” on the image, or not at all if it’s a full-width number. They then have to manually remove the width and height attributes the builder automatically applies because they don’t jive with the responsive nature of the site design.

If caption, they don’t use the css class field at all. Enter “figure” in the wrap tag field. Remove the godforsaken width and height values that are added. Paste the code in place. Add a class on the figure element (left, right, or none). And insert <figcaption>...yadda modda...</figcaption> before the closing figure tag.

Also, client says “I’m probably going to just use the “XHTML” link from the Images list. I said wise choice considering the potential for having to build a figure and figcaption composition, which isn’t going to be as straightforward (or possible) with the other two builder options.

Anyway, what I want to say from this is:

Maybe drop the useless fields like ID selector and Caption from the tag builder that don’t really serve any value for looking ahead at HTML5. (Jeremy Keith says you should rarely need to use ID selectors anymore, or so the trend is headed, anyway.)
(I have no idea what the Escape field was ever for. Have never used. Always confused clients.)
Make the class field configurable so one can define specific class value options as a selection menu.
Add another class field that can be applied to the wrap tag element, if it’s used.
Going back to #1 about Caption…maybe instead of removing it, turn it into a real fig caption field that outputs the text string wrapped in figcaption tags and inserted in the proper place of the snippet.
Stop using “XHTML” in the UI. “HTML” makes more sense considering the direction.
Do not add the width and height attributes on generated tag builds, please.

Then unrelated to the client site, I started wondering why there are the three links in the images list, confusing the client at the outset, and why there’s not just a single link for “Tag Builder” or something…saving a little space too. A designer could then configure the “Type” menu to default to the one a client wanted so there’s no difference in click numbers from list view to building a tag, yet improvement to the UI and thus client understanding.

After some searching I (re)discovered I asked about the links before in 2006. Ha! Though I think my case for a single “Tag Builder” link is stronger now, and may even counter Zanza’s counter to my original argument. :)

Last edited by Destry (2011-08-24 16:38:18)

Bloke · 2011-08-24 17:25:19

Destry

A curve ball on this topic is to use a plugin like jmd_img_selector to add images to articles.

If that’s your mug of chocolate I happen to have a plugin based off that which is a halfway house between jmd’s plugin and smd_macro. It allows you to define classes to add to each inserted image. You can give the definitions nice client-friendly names like “Left” “Center” and “Right”, which behind the scenes adds class="regular", class="alternate" or class="full" (or whatever) when you add the images to either the article image field or body.

It of course does a lot more besides:

Allows you to define custom insertion macros (which can actually use smd_macros if you’re really mad!)
Can aplpy macros to each image or to the group of selected images as a whole (handy for image gallery creation)
Remembers your most recent insertion method for next time
Integrates with smd_thumbnail so you can allow people to insert a different size of image
Some handy prefs for customising which bits of the interface to show to the customer
Filter by category
Use select all / none / range / toggle buttons to rapidly pick groups of images for insertion

It’s just about battle ready, although there are three things yet to address:

I’ve had a recent report from maniqui that sometimes it doesn’t behave, but I can look at that.
It can slow down if you have either very large or lots of images, because it currently uses the same mechanism as jmd_img_selector in that it downloads the full size pics and squishes them into squares — not good. I need to offer the option to grab thumbs / smd_thumbs instead to keep the speed up.
Again, because it started life as a rip of jmd’s plugin, the underlying engine is still about 75% written in raw DOM javascript code. It needs a cleaner separation between server and client, and all the code migrated to jQuery.

There’s also one HUGE improvement that I want to make to it but I’m keeping that under wraps for now because it’s a lot of work, but it’ll hopefully blow the doors off the image handling workflow.

However all that is just “stuff”. The basic plugin works today, so if you’re interested then please get in touch.

As to the Images panel itself: yeah, the three tag builder links always grated but since I never use them I just gloss over them and kind of forget they’re there. When we (jakob, jstubbs, me) dived into a coding playground for a grid-based images panel last year we pretty much did what you suggested and made the tag builder a single popup link. Much cleaner.

When we come to remodel the panel we’ll take all this onboard. In the meantime, shout if you want to try the plugin approach.

Last edited by Bloke (2011-08-24 17:30:46)

jakob · 2011-08-24 19:39:14

Stef’s answer probably deals with a lot of your stuff, but a half-way house might be to use smd_macro as Stef also hints at. By way of example, here’s a post with an smd_macro for an html5 figure / figcaption with a class. You could expand on that as needed.

EDIT: An afterthought: I vaguely remember there being some talk about possible textile plugins that bolt on new functionality to textile. Then again, maybe I was imagining it or wasn’t reading carefully enough. Steve or Stef, can you clarify?

EDIT 2: No, I wasn’t imagining it :-)

Last edited by jakob (2011-08-24 19:43:04)

Destry · 2011-08-24 19:46:31

Stef,

I’d love to have a look at it. And thanks for mentioning smd_macro. I read the overview of that a while back and made mental note to look into it closer; it seems like it has all kinds of crazy fun potential.

I have nothing against plugins. I just mention all this because not everybody I give sites too can handle the necessity of keeping up to speed with plugin upgrades and whatnot, let alone base install upgrades. Heck, even content architecture and content itself seems to go down hill the second you hand the site over. So while it seems obvious to us a lot of the time that a plugin or mod to the backend or whatever is an easy skirt of the mud, it’s rarely a win for the client who just wants stuff to magically happen.

I was even reluctant to to edit the tag builder via CSS for fear it would be gone on first upgrade, but I realized it was in the theme (smart) and not some core CSS file. As long as they don’t overwrite the themes file (relatively easy to document against) that should be okay and they can forget about it otherwise. Those are little wins for certain projects, but the more these little things are improved in core, the better for situations like I often seem to be in.

Ed. Oh, sweet, Jakob. Now I do have to look at smd_macro sooner. :)

Last edited by Destry (2011-08-24 19:50:36)

Bloke · 2011-08-24 23:40:26

Destry wrote:

I realized it was in the theme (smart) and not some core CSS file. As long as they don’t overwrite the themes file (relatively easy to document against) that should be okay

If you want to defend against that, temporarily install smd_admin_themes and make a new theme called destry_classic or something. Clone it from classic. Go to the smd_admin_theme prefs, set your cloned theme as the default global theme and then you can alter that theme to your heart’s content without fear of upgrades bashing it.

smd_admin_themes can be uninstalled at that point too if you want to keep the plugin count down; it’s done its job by then. Although it is handy for editing themes and of course switching them or testing them before releasing to the userbase.

Last edited by Bloke (2011-08-24 23:42:53)

Destry · 2011-08-25 08:00:11

Bloke wrote:

install smd_admin_themes

Definitely something else I’ve been meaning to get to, for a number of reasons, like building a theme I’ve had in mind for a while now, and working on this, which people in the socialverse are already gabbing about being missing.

Thanks again, Bloke.

Textpattern CMS

Textpattern CMS support forum

#1 2011-08-24 16:31:17

Images panel thoughts

#2 2011-08-24 17:25:19

Re: Images panel thoughts

#3 2011-08-24 19:39:14

Re: Images panel thoughts

#4 2011-08-24 19:46:31

Re: Images panel thoughts

#5 2011-08-24 23:40:26

Re: Images panel thoughts

#6 2011-08-25 08:00:11

Re: Images panel thoughts

Board footer