Inlay dilemna

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):

  1. Account creation and billing.
  2. Site creation.
  3. Editor assignment control. (Who can edit your site besides you.)
  4. 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…”)
  5. Site management (create and delete virtual pages in a fairly accurate duplicate of the Freeway interface – entirely in a browser).
  6. Content and metadata editing for virtual pages.
  7. Live in-page editing for virtual pages (in your page, click an element to edit it, click elsewhere to save changes).
  8. New HTML content format for “code stuff™” that you need to manage without any hand-holding.
  9. String content format (one line of text, like a headline or footer).
  10. 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
  11. “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.

Any thoughts?

Walter


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

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?


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

WYSIWYG is better, even if it’s ugly like Tiny.

I tend to agree with Todd.

To a client Markdown is scary unknown stuff and they will avoid using it.

David


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

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


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Dave, I don’t understand. Could you explain?

If you’re designing a responsive site that last thing you want is a WYSIWYG editor (no tables).

Perch has been using a Textile editor from day one and none of my clients like it. I think they’re accustomed to Tiny and the like.

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.

Todd


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

My mistake, I meant David, not (Delta)Dave. I’m all turned around.

Todd

Dave, I don’t understand. Could you explain?

If you’re designing a responsive site that last thing you want is a WYSIWYG editor (no tables).

Perch has been using a Textile editor from day one and none of my clients like it. I think they’re accustomed to Tiny and the like.

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.

Todd


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

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:

Dave, I don’t understand. Could you explain?


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

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.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

I am approaching this product as a user - clients hire me to do stuff for
them. I like Markdown and would be perfectly happy with that kind of UI.

I always look at the Matrix encoded.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

I’m a red-pill guy myself, too.

Walter

On Aug 24, 2014, at 11:19 AM, Ernie Simpson wrote:

I always look at the Matrix encoded.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

The dilemma of it is:

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.

It furthermore needs to recognize my

.supercoolbodytextclippingstyle {style-types: awesome;}

(some would call it paragraph) and naturally this

.style178 {style-type: I think headline;}

You know what?

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.

Cheers

Thomas


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Karen McGrane: Adapting Ourselves to Adaptive Content - An Event Apart on Vimeo

That was an inspiring discussion - thanks Thomas!

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.

:slight_smile:


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Interesting. I watched the whole thing.

Todd

Karen McGrane: Adapting Ourselves to Adaptive Content - An Event Apart on Vimeo


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Interesting. I watched the whole thing.

Karen McGrane: Adapting Ourselves to Adaptive Content - An Event Apart on Vimeo

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.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Blobs vs. chunks. That’s a much better explanation to the point I was making.

David

On 25 Aug 2014, at 13:26, “Thomas Kimmich” email@hidden wrote:

Karen McGrane: Adapting Ourselves to Adaptive Content - An Event Apart on Vimeo


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

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.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options