I have been sweating one last detail for the past two weeks, putting off launching Inlay because of this one thing: WYSIWYG.
I have had a WYSIWYM (What You See Is What You Mean) editor for Markdown for over a year, and it works perfectly. Other page elements that are marked as a simple string (text) content just get a normal HTML input field and the contents of that field are magically styled to look just like the template.
Those two should be enough to begin with, and yet I fear that without the all-singing-all-dancing live editor for “rich” HTML, I’m not going to appeal to the masses. I’ve tried a bunch of them, and either had compatibility or technical issues, or I just thought they were awful to look at.
So, masses, what say you? Will you (and more importantly, your clients or other content editors) be happy entering content in Markdown or single-line text input fields? Or are you holding out for more?
Here’s the current feature set of the system (all complete):
Account creation and billing.
Site creation.
Editor assignment control. (Who can edit your site besides you.)
Template creation in Freeway (with an Action) or a text editor. This is the killer feature, IMHO, because ANY page can be a template, and you don’t need a course in quantum physics or computer science to figure out which bit of code to change to make your header look different. (As a colleague just said, “You poke it here, but it squeals over there…”)
Site management (create and delete virtual pages in a fairly accurate duplicate of the Freeway interface – entirely in a browser).
Content and metadata editing for virtual pages.
Live in-page editing for virtual pages (in your page, click an element to edit it, click elsewhere to save changes).
New HTML content format for “code stuff™” that you need to manage without any hand-holding.
String content format (one line of text, like a headline or footer).
Markdown content format. (Your HTML template placeholder is converted to Markdown for further editing.) The Inlay documentation site uses this now: http://docs.inlay.io
“Round-trip” template updates: change the layout in your Freeway document, upload, press a button on the Inlay control panel, and all your virtual pages change to match.
I fear that I may be holding back from the brink because I’m worried that people will not think this is enough to use now. I am seriously considering just pushing the button this weekend and seeing where the chips fall.
I’ve tried Markdown for tech-challenged clients and they all intensely disliked it. Therefore I’m inclined to think - given your target audience - that WYSIWYG is better, even if it’s ugly like Tiny.
Todd
So, masses, what say you? Will you (and more importantly, your clients or other content editors) be happy entering content in Markdown or single-line text input fields? Or are you holding out for more?
I’d worried about this. If you’re designing a responsive site that last thing you want is a WYSIWYG editor (no tables). The new Perch site’s are using Textile or Markdown and do you know what? No client so far has mentioned there’s an issue using it.
David Owen
On 23 Aug 2014, at 15:00, Walter Lee Davis email@hidden wrote:
I have had a WYSIWYM (What You See Is What You Mean) editor for Markdown for over a year, and it works perfectly
A full WYSIWYG edit allows the client to style content potentially bringing in inline styles or even tables into content. It’s the clients job to add the content and the designers job to do the styling.
Having full WYSIWYG mean you will get someone deciding that bright green 110px text is fine. Or creating a table across a 600px column which breaks horribly at phone size.
David
On 24 Aug 2014, at 05:27, Todd email@hidden wrote:
I often hear about the bonehead things clients do with editors but I’ve not experienced it myself. The biggest problem I see is that they don’t use lists when they should.
Besides, you can always customize the UI, that has proven to be a good deterrent.
Todd
A full WYSIWYG edit allows the client to style content potentially bringing in inline styles or even tables into content. It’s the clients job to add the content and the designers job to do the styling.
Having full WYSIWYG mean you will get someone deciding that bright green 110px text is fine. Or creating a table across a 600px column which breaks horribly at phone size.
People (let’s call them client) wants to have a big white area, preferably nothing in and round about. The reason for this is, that they expect changing bg-colors, area-bg-color and so on.
In this area, they need a carousel, fully customizable, let’s say images combined with text. This is just because they change the appearance of carousel each day - PROMISED.
And beyond this, each carousel is followed by a sound-file singing a Hooray - mostly.
For exact this reason we are discussing hundreds of CMSes and exact the same amount of editors.
What I’m after is best described by Miss Karen McGrane.
Start at 6:50 - 10:34 (just 4 minutes to go).
To be honest - I haven’t understood everything in detail - but it is about taxonomies (custom field entry mask) - Markdown would be way enough.
I’m really curious what you think guys - an API for local CMS but even for to use “everywhere”? And got the certain feeling, that INLAY could theoretically serve this needs (consequently thought), cause its editor knows what he does.
While I totally love the early discussion of content design, the whole vid
was worth the time spent and then some. Something to grow my mind and dream
on.
This does twist this conversation a bit - of CMS editing tools I mean. The
wizzy ones are tasked with assigning visual styles to content, but what
about a semantic editor - which would allow CMS users to markup the
content more meaningfully - as the appearance has likely already been
seen to by the designers.
I ramble perhaps, but I like the idea of a semantic editor.
I think the XStandard editor is kind of pointed in that direction. Perhaps not to the extent you’re describing but certainly more so than any other editor I’ve seen thus far.
Todd
The
wizzy ones are tasked with assigning visual styles to content, but what
about a semantic editor - which would allow CMS users to markup the
content more meaningfully - as the appearance has likely already been
seen to by the designers.
