Symphony.

After a long time I'm still struggling to find an elegant solution for text/image input.

I like markitup/SSM drag and drop but it doesn't look pretty to clients. CKEditor looks better but doesn't provide functionality I like and is too hard to modify.

Client: But in Wordpress it's got a cool thing where you can put the image in the box with the words.

Developer: Yes but there's this stuff in the background that you aren't aware of and can't see that's really important for upholding these standards that you've never heard of and don't care about. Yes it all does look the same to your customers browsing the site...

What's everyone else doing?

I have a lot of — even big — clients. Many of them complained when I said: "You will have to learn Markdown". My answer always was: "Let's try for two weeks." In the end all of them are very happy, because Markdown is very simple to learn, and still it gives them the feeling that they have gained some "secret knowledge" about semantics and the web.

So I never ever used any What-you-see-is-...-what-the f..ck-is-this? editor.

Nice one liner, I get what you mean, the larger clients aren't a problem especially if they've been fighting some awful IE6 based intranet DB app for years. They can handle a bit of markdown.

Markdown's defo the best thing all round. But, some sort of preview pane would be sweet. I find myself with two or three browser tabs open at times, feels like coding a site rather than editing a bit of content.

Markdown is ok for headlines and making some words bold, but even I couldn't really remember the syntax for images and links, so how can I expect a client who edits his content maybe every two month to do so? Besides, the content gets really messy, so I switched back to TinyMCE after a while.

Images are still a problem though, but I'm planning to work on a new HTML5 based WYSIWG-extension later this year that also provides a somewhat Wordpress-like solution for image upload and management.

Extensions like Subsection Manager are great and maybe more in line with Symphony's principles and philosophy, but it simply doesn't fit some very common and basic use cases.

a somewhat wordpress-like solution for image upload and management

Have you ever seen a WordPress-Website managed by unexperienced users? Their solution is by no means clear and simple. Plus: They write HTML to the database, which is nothing you would like to parse later. Markdown can always be parsed and re-used.

even I couldn't really recognize the syntax for images and links

I have more than a hundred websites doing exactly this, adding images and links using Markdown. How many do you have who can not do it? :-)

(OK, I admit that I help them sometimes by providing "code to copy into your text" when they upload files.)

I'm facing this with a client now. They love the ability to re-size an image in WordPress.

Michael, what's your usual section/field/extension mix to combat this with markdown?

Massive fan of WYM and despise any client requests for WYS editors. Using Markdown means that it's reusable, should the site design change, then the CSS will take care of how the typography will look.

Same deal for images. Resizing logic can be done with JIT in the XSLT depending on where the image is placed (using the SSM drag & drop feature) or where the content is being displayed (index, list view, detail view). That means if the design is updated, the content doesn't have to be updated as well, just the XSLT.

COPE

what's your usual section/field/extension mix to combat this with markdown

Standard article images — if any — are in the article section, of course. There is a second section for "files" (maybe using the Unique Upload Field extension), which may be images or PDFs.

You may use JIT URLs for images to "see" the size of the image and resize it "on demand" in XSLT, as @brendo mentioned. Here is a screenshot of the "code to copy to your text" functionality (using frontend publishing in a German web application):

The same could be done in the backend using the HTML Panel Field extension.

(Parsing the resulting HTML image tags in order to resize the images requires the Ninja Technique, of course.)

Attachments:

code-to-copy.png

To make things more clear: As you see, I am not a fan of the "do everything on a single edit page" idea. I rather focus the user on the current task. Write something? Go to the article (index/new/edit) page. Upload (or use) a file? Go to the files (index/new/edit) page. Copy your file's "insert code" from there to your article.

It's not a bad idea, as you may think. Finding several tasks on one edit page can be stressful to users. Needless to say, by doing things like this I don't need any special extensions.

Brendan beat me to it and mentioned COPE.

Maybe what's bothering me is how Symphony is excellent for many applications, especially large ones that would be tedious to create otherwise. But... it's difficult at this point do 'some' seemingly simple stuff easily.

I'm not a fan of Wordpress at all, or of blogs really but building something similar with WYS that's a fairly standard feature of such sites can become a bespoke coding task that the site isn't worthy of the time spent on, or a workaround for clients that makes Symphony look a bit odd if you do markdown instead (at least to the uninitiated).

Don't get me wrong, I'm fully commited to WYM and would ideally want clean entries in the DB.

I'm not fussed about image re-sizing or even floating in a textarea, I think that's part of the site design and not for clients. If you're creating page blocks with paragraphs and images it's helpful to see where the text flows and if you can keep images lined up with the paragraph they relate to.

I mostly SSM/drag and drop then ninja the output but at what point do these image URLs and stuff in my DB textarea entry become classed as junk and not clean?

Also if I drag and drop a SSM with and SSM inside the drop text of the nested SSM doesn't go over, the text from the caption part does.

For my own personal sites I feel like entering my own data is a bit of a workaround to produce paragraphs with images floating right. I started this thread as I'd begun to wonder if I was missing something but it seems we're all facing the same options.

For me, it's either wait to see if people develop some neat extensions (which is lazy and bad) or learn more about developing and try to do that myself, which is a good thing to do anyway and something I should do for practice but again, how much work is this to accomplish something that just flows text round images.

Really interested in what everyone's solutions are, keep it coming...

Using Markdown means that it's reusable, should the site design change, then the CSS will take care of how the typography will look.

I use the same approach with TinyMCE by only providing structural options without styling, like headlines, paragraphs, bullet points, ...

OK, I admit that I help them sometimes by providing "code to copy into your text" when they upload files.

And that's exactly the problem. Clients shouldn't have to care about code or learn a new Syntax for simple things like making a headline or including a link. And if I as an administrator/developer want to code something directly for some reason, it's also easier to do so in plain HTML compared to learning yet another syntax.

I don't agree. Markdown is by far the best Syntax for writing on the web. My authors love it; I don't have a single one complaining about it. And even I myself (who knows HTML) am much faster using Markdown compared to HTML. And I love the readability of Markdown.

@munki:

it's helpful to see where the text flows and if you can keep images lined up with the paragraph they relate to.

The clients' expectation is the problem. It will never work. Change the browser, and the text will flow differently. Clients who want to "design" their articles like this probably also had a training in "Designing with MS WORD", and — even worse — they still believe that they learnt something useful there.

Anyway, this shouldn't be a philosophy dispute. If someone ever comes up with a working WYM or WYS solution, I am all ears. Maybe I can learn.

@michael-e

I guess it always depends on the use case. If you need it on a regular basis it's less of a problem to learn it once and just keep going. But it's harder to remember an even relatively simple syntax when you only use it every now and then.

I really tried it and even recommended it to clients because I thought it was simpler and more elegant, but I quickly changed my mind because of client feedback and my own experience.

@michael-e

"@munki:

it's helpful to see where the text flows and if you can keep images lined up with the paragraph they relate to.

The clients' expectation is the problem. It will never work. Change the browser, and the text will flow differently. Clients who want to "design" their articles like this probably also had a training in "Designing with MS WORD", and — even worse — they still believe that they learnt something useful there. "

Cheeky, I was talking about me inputting stuff there :P

I get what you're saying about MS-Word and clients though.

@michael-e

I don't agree. Markdown is by far the best Syntax for writing on the web. My authors love it; I don't have a single one complaining about it. And even I myself (who knows HTML) am much faster using Markdown compared to HTML. And I love the readability of Markdown.

If it confuses my mom (and it would), there's room for improvement.

Muggles can learn a great deal, even HTML, but that doesn't mean making them learn is good UX. Steve Jobs would come back from the grave and strangle you twice if this were your iSomething app. :-)

I don't think an editor should allow WORD-like control of the content. But it should allow users to build, review, and edit that content with the least hassle possible. Ideally it would:

• provide an automatic preview mode (not click to preview)
• represent dropped content with click-to-edit icons, placeholders, or previews
• drop unique content identifiers by default (not URL's or other editable data)
• display configurable dropped-item settings on the toolbar when the item is selected (size, float, HTML attributes a user might need to control)
• support MarkdownExtra++^2
• include an Anti-Writer's Block button

It's a tall order that may require SSM and Markitup to engage in lewd and improper contact, maybe even inbreeding. But I think you could do it, and you probably need a break from more important things anyway. :-)

@munk

For my own personal sites I feel like entering my own data is a bit of a workaround to produce paragraphs with images floating right. I started this thread as I'd begun to wonder if I was missing something but it seems we're all facing the same options.

I settled with a simple syntax in the alt text brackets that I could parse and strip for basic styling choices without precise control (s: small, r: right, v: vertical, etc.). For example, my drops would look like this:

![(svr)Worms Fighting to the Death](permakey/bai-496)

![Slime Mold Racing](permakey/video/bav-512)

@BBQbrains

Heh heh, if Steve Jobs comes back from the grave I'll have to strangle him twice *wink

I've done something similar with my drops but had to go more complex. I'd mentioned above that I can't get at the drop text of a SSM inside an SSM but could get to the caption text. I've had to split all the field identifiers up seperated with some marker text and ninja it into a proper structure.

I know it's not smart but it worked for that use-case, but then it's not really proper markdown. The reason for this was to have images with alt, but also some small note text and/or image owner credit below that's floated with the image.

Out of interest, is:

![(svr)Worms Fighting to the Death](permakey/bai-496)

actually markdown? It's certainly markdown like.

For anyone reading who hasn't messed with it yet, you can put any markup type stuff you need into the drop text box of SSM along with the {$params} but you can't in the caption box. For a use-case with SSM not nested in another SSM it's entirely possible to provide a drop that gives quite detailed markup in markdown or html format. - although the drop text box is a small one-line format.

I think something that can preview the markdown in a live way, and some non-nested SSM or improvements to SSM (I don't know if they'd be a big or small edit) would solve things for me. Aside from the inherent problems with SSM and other similar extensions with regard to large image galleries etc.

I've enjoyed learning Symphony and quite a bit of XSL, I guess I'm at a point where I should start messing with extensions. I need to change hosts or do something to use 2.3, I suppose it's a bit redundant to learn new stuff for < 2.3 at this time.

@munki

I've done something similar with my drops but had to go more complex. I'd mentioned above that I can't get at the drop text of a SSM inside an SSM but could get to the caption text. I've had to split all the field identifiers up seperated with some marker text and ninja it into a proper structure.

So far I've avoided nesting. If you need to get drop text from a nested SSM, you could try a Reflection field with identical text. Except for the alt text and id, I don't include any entry data in the drop. All that comes from a separate data source using the id to match the entry.

This

![(svr)Worms Fighting to the Death](permakey/bai-496)

is a repurposing of Markdown's image syntax:

![Alt text](/path/to/img.jpg)

That way I don't work against Markdown, and I get a node in the xml.

I prefix the alt text with an optional user-entered styling code in parentheses and replace the real path with a drop type and unique identifier (permakey) based on a section abbreviation and entry id (ex: doc/permakey/pcd-234). Then I can use a single template to format all drops, know where the drop originates, and don't need to worry about broken links when URLs or names change. If a drop goes missing, I can kill the image node altogether.

I'm about to hand off an install to my wife so she can run a blog/gallery for herself. I can then quantify the UX grief with nag analytics. :-D

nag analytics

pmsl.

is a repurposing of Markdown's image syntax

Which is one of the great things about markdown + XSL. As long as the syntax outputs correctly from markdown conversion, you can use the Ninja technique to do another conversion at template level using set rules to output the right data!

I am a big believer in Markdown and keeping design away from clients, but I completely agree with needing a 'preview' of your markdown. There is the HTML panel field available, but I reckon there would need to be some hybrid of that with a JavaScript function or two to preview it correctly, as the HTML Panel field requires a save to view the entry XML.

I would love to do this, but alas time is ever shrinking. If these guys can do it, why can't we? (food for thought)

@BBQbrains

That's a neat workaround. I think you can do it with just SSM drop text box as it does create a node, well looks quite like a node to me. I think it might be a child node or something. Works anyway. Plus you can workaround my way with the caption box, cos dammit I'd nested those SSMs before I noticed the restriction.

@designermonkey

That's very interesting and perhaps also for other stuff too? I might have a try, no experience with extensions so far but you've got to start somewhere. I guess all the data is in the DOM before anything gets saved.

Like the new avatar BTW, gardeners thumb this time?