Wysiwtfftwomg

http://www.markboulton.co.uk/journal/wysiwtfftwomg

by Isofarro • 13 years ago

131 85 13 years ago

markboulton.co.uk

bcoates2• 13 years ago

I'm pretty sure that what people want when they ask for WYSIWYG is live editing -- they don't want a "compile" step in their editing process, it's a gigantic productivity sink.

The actual act of editing something by trying to manipulate its output representation is usually painful, which is why WYSIWYG sucks for anything but demos to people who buy software but don't have to use it. The one thing it does get right is live editing, but you don't have to do WYSIWYG to get live editing -- you can just have a splitscreen with a sane, editable, logical representation on one side and an instant preview on the other.

qznc4• 13 years ago

I think the point is that "preview" is broken concept too.

The text you are writing will be read on smartphones, tables, PCs, and TV. It will have different layouts, e.g. depending on screen size. Which one do you want to preview?

bcoates2• 13 years ago

All of them? I don't think there's a way around that, including expecting the people writing your copy to operate in the abstract realm of responsive CSS or whatever.

There's no way around thinking about your use-cases and you're not going to convince designers to not want to see what the end product actually looks like.

minor_nitwit2• 13 years ago

Use the responsive design view built into firefox and try the different screen sizes. You still are going to care 'how it looks' on all of the devices you expect to see it. I understand that it's nearly impossible to control for every screen size, and maybe that's the point, but you should still know and understand what most users will see.

dools11• 13 years ago

As long as the tool you're using doesn't allow people to inject arbitrary presentation instructions (eg. font size and style) along with the content you can safely allow people to enter their content on one device and know that your responsive style will handle the rest. We are solving this problem and looking for feedback at http://www.decalcms.com/tour/

jonhohle• 13 years ago

The one thing it does get right is live editing, but you don't have to do WYSIWYG to get live editing -- you can just have a splitscreen with a sane, editable, logical representation on one side and an instant preview on the other.

Years ago I did exactly this for an internal CMS. The preview window used the same renderer as the front end, and there were various dynamic controls the authors/editors could use to control content, reference other content, etc. The preview window would update as they typed and always look like the current styles. If someone went overboard with direct styling, it would be painfully obvious during review, since reviewers first saw the raw content.

The system also had a "cheat sheet" which would show technical writers all of the supported styles and snippets in both literal and rendered forms.

qznc4• 13 years ago

Nice story, but the important part is missing: Did it work? Did people accept that? Is it already replaced by something else now?

3pt141593• 13 years ago

This is why I'm so fucking angry at the state of contenteditable. It could have been awesome, but its a complete disaster. If you want anything good (say, autoembedding youtube videos) you essentially have to use text area and fake the whole thing. Like managing cursor state and switching elements.

mden• 13 years ago

Contenteditable fails in many ways, but it's still something quite awesome and provides a good basis to build on. I built myself a wiki system because I find the current ones to be a huge pain to edit and I'm using contenteditable as the main tool. No need for separate editing pages, markup languages, or other nonsense - just click edit and make the changes immediately. I agree that contenteditable could have been way better, or in the very least more consistent between browsers.

dools11• 13 years ago

Yeah it's a nightmare, but you can wrangle it with enough work... try the demo here and see what you think: http://www.decalcms.com/tour/

edwinyzh• 13 years ago

Wow! This almost exactly what I feel about html editor and why I'm working my live html/css editor (http://liveditor.com) !

Can I quote your response somewhere on my website to explain the idea of LIVEditor?!

the1• 13 years ago

a dynamically structured <form> is much faster for content people to work with than contenteditable crap.

our flow is like:

* does content have more than X number of words? * yes: prompt if the content has to be promoted as special "tweet" like feature * is the content tagged as Y and Z , or A, or B and C? * yes: prompt for other ways to promote the content. * does the content include video? * yes: prompt if the content needs to be featured in video playlists in a section page. * is it also tagged as D? should it be promoted in another section's hot-play list? * ...

our content people start with simple form asking for title, author, tags, and content (html). the content is parsed to see if any of our media (image, video, audio) is embedded. if our games are included... etc. And depending on the title, tags, author, content new input fields are injected dynamically.

order of dynamic fields are carefully chosen so that workflow is optimal.

we initially went with contenteditable blocks (or components). that failed miserably: database became complicated. We ended up building something similar to DOM tree in database.

start with a simple form. analyze user input. dynamically add/remove more fields.

cabirum2• 13 years ago

Once we go beyond plain text editing, WYSIWYG becomes quite useful. E.g. even a simple table looks ugly in wiki[1]/markdown[2] format, and manually aligning columns with pipe characters is painful and time consuming. Then there are images, charts, TOCs, footnotes, and many more content types that cannot be intuitively represented in plain text.

[1] http://en.wikipedia.org/wiki/Help:Table/Introduction_to_tabl...

[2] https://github.com/adam-p/markdown-here/wiki/Markdown-Cheats...

egeozcan3• 13 years ago

It doesn't have to be plain-text. It just needs to be structured, unlike a WYSIWYG editor. Recently I discovered a library called Sir Trevor JS[1] and thinking about adding a table block to it.

[1] http://madebymany.github.io/sir-trevor-js/

cabirum2• 13 years ago

I think it's easier to add "constraints" to existing WYSIWYG apps, than to create something from scratch. Like, take MS Word and enforce using only styles (no inline formatting), no more than 1 consecutive space and line break, etc. In the end, you'll get a well formatted XML.

dools11• 13 years ago

We're working on a way of allowing designers to deploy arbitrarily structured, editable content with a truly wysiwyg editor: http://www.decalcms.com/tour/ what do you think?

overshard• 13 years ago

As someone trying to solve the problem of Word to CMS copy/pasting, this is sadly what the majority of people do. As someone trying build build responsive websites I see people adding a bunch of spaces to center align instead of using the "center align" functionality this kills me.

I don't know the right solution, I've tried just about every editor and nothing seems to stop the Word to CMS copy/paste issue. Maybe the solution is to build a Word plugin to publish to CMS that cleans up the content as it publishes?

egeozcan3• 13 years ago

That's actually not a bad idea at all. Word Plugin API, I assume (I don't even use Word, let alone making plugins for it), may give you the structure with the content and all you have to do would be just splitting that information to put into the right fields.

I'm actually thinking about giving this a go (I guess I need to purchase a Word license at first).

bithive123• 13 years ago

The point is that people have a hard enough time using the existing features in Word and other WYSIWYG editors which allow for structured documents. Once an enterprising individual decides to depart from your template using tabs and spaces you will be helpless again.

mikecane• 13 years ago

Responsive Design is what eBooks had since the first ePub spec. The ability of the user to control all aspects -- typeface, type size, line spacing, justification on/off.

With the advent of the iPad, we've a surge towards fixed layout.

Go figure.

liotier• 13 years ago

Pseudo-WYSIWYG is enough in most use cases: the user doesn't actually want a pixel-perfect view of the final rendering - he just wants familiar graphical hints of his document's structure.

esw• 13 years ago

It depends on the user. In my experience, older users (55+) are particularly incensed when there's any inconsistency between what's visible in the editor and the outputted page (e.g. "I've been trying for hours, but I can't get the 'e' in this line to line up with the 'h' in the line above it!").

djs070• 13 years ago

I'm yet to find the right way to have clients "buy in" to the concept of limited wysiwig functionality, as it can be hard to explain what they're gaining in return without long-ish term exposure to the underlying technologies. Maybe an open-source document would be handy to help us get the key points across to "content peoeple"?

smacktoward3• 13 years ago

In my experience there's no silver bullet way to sell it, but there are some ways that work depending on who your audience is.

If the audience is management, the gain is control. "You just spent umpty million dollars redesigning your visual identity, you don't want some low-level copy jockey deciding to throw all that out and publish a page on your site entirely in Comic Sans, right?"

If the audience is the people who actually have to use the software, the gain is simplicity. "Look at this editing window from your current system. It has four toolbars, with fifteen buttons on each one! Do you really know what all those buttons do? Do you really want to be responsible to your boss if you hit the wrong one and screw something up? Now look at this other editing window. Isn't it clean? Doesn't it look easy to use?"

dools11• 13 years ago

We're creating a way to provide a truly wysiwyg experience whilst allowing the designer to impose structure and constraints through html and css: http://www.decalcms.com/tour/ what do you think?

DanI-S• 13 years ago

I suspect many people create their content in Word because they have learned the hard way that sometimes, when you click "Submit", the page goes blank and you lose all your work.

mintplant• 13 years ago

Lazarus [1] solves this problem. It auto-saves what you fill into forms, and allows you to go recover previous versions. You can right-click on any input, pick a saved copy, and restore.

Firefox: https://addons.mozilla.org/En-us/firefox/addon/lazarus-form-...

Chrome: https://chrome.google.com/webstore/detail/lazarus-form-recov...

Safari: http://getlazarus.com/download

LordIllidan• 13 years ago

Doesn't seem to work for WYSIWYG fields in Chrome:

ALSO NOTE: Lazarus 3 doesn't save WYSIWYG editors yet, this is due to a Chrome bug (http://code.google.com/p/chromium/issues/detail?id=20773) which prevents us from accessing the iframe that is used to display the editor. There's little I can do until this bug is fixed, sorry.

vacri• 13 years ago

Unknown or expired link.

Samuel_Michon3• 13 years ago

I think the solution for content creators and content managers is not to copy and paste from full fledged word processors like MS Word, LibreOffice, and Apple Pages. Write plain text documents in Notepad (Win), TextEdit (OS X), or whatever plain text editor their BSD or GNU/Linux distribution offers. If they want to add styling, have them use Markdown or Textile and have a CMS that parses it.

For small sites, I use Textpattern. Contributors can write content in plain text with Textile tags (if they choose to do so).

For larger sites, I use Drupal. Contributors can write content in plain text with Textile or Markdown tags (if they choose to do so).

That way, the brand gudelines are upheld and contributors don’t have to think about styling too much (and if they want to disrupt, they can’t).

Hemospectrum2• 13 years ago

If they want to add styling

The problem for a lot of users is the disconnect between a logical style (the actual boldness of the text) and representations of that style. If you haven't learned to handle this kind of abstract symbolism, plain text markup formats just don't make sense to you. Your brain instead registers it as a combination of "this editor doesn't have bold for some reason" and "the computer garbled my copy and made parts of it bold for some reason" without ever drawing the connection between one and the other.

This is only really an issue in places where abstract thought is seen as an innate ability which can only be tested for and not taught to people. Unfortunately this includes the US.

Samuel_Michon3• 13 years ago

I read your comment several times. I don't understand the distinction you're making. I feel dumb. Could you explain it in another way? I'm sure your comment has value, I just don't understand it.

In languages like Markdown and Textile, one doesn't need to worry about presentation, it's all about semantics.

smacktoward3• 13 years ago

the solution for content creators and content managers is not to copy and paste from full fledged word processors like MS Word, LibreOffice, and Apple Pages

A solution that boils down to "take all the tools in your workflow that you're already familiar with and throw 'em out the window" is not going to go over well.

Those of us who work in the content-management space have been trying to get people to understand "pasting from Word is bad and will break your heart" literally for decades now. It never works. Word is the only composition tool many of these folks are familiar with, and that familiarity has only come because (from their perspective) they've had to fight with its idiosyncrasies for so long that they finally know where all the land mines are. The idea of having to go through all that all over again with a new program is frightening, so they hold on to Word with all their might.

It's possible that eventually Word will become less of a problem, not because it'll get better but just because a generation of writers will grow up who are more familiar with Web writing tools than offline ones. But we're at least a couple of decades out from that being the case, alas.

curveship2• 13 years ago

I used to edit books, and had the privilege of working with a few well known authors, people whose names you'd know if you follow fiction.

One of these fellows spent his personal money to get three copies of his book laid out, in three different fonts. The look of the book was that important to him.

Am I supposed to lecture him that he should be thinking about "logical structure" not appearance? That I know what books are about more than he does?

Samuel_Michon3• 13 years ago

I believe you’re confusing a few different stages in the book creation process. Also, the submission you’re responding to was about web publishing, not print.

I publish printed books for a living. I’ve been involved in the design, editing, and marketing of printed books for 20 years.

Unless the person you speak of self-publishes, he doesn’t pay anything for the lay-out of the book. If he does self-publish, and he has retained someone to make it into a half-decent book, then yes, that person should advise him about logical structure and appearance (depending on what that person is paid to do.) And yes, hopefully, the person he pays to help him does know more than him about creating books and shouldn’t be afraid to give his professional opinion.

Remember, a manuscript does not a book make. Experienced authors know this and value publishers.

curveship2• 13 years ago

I respect your experience in publishing, but I think it misses my point. It may be that you work with different genres. My point was that for many authors, particularly authors on the high end of the fiction market, appearance does matter to them. These people love books, not just the words but the physical feel and appearance. They have opinions about the physical form their book takes. Are they wrong?

I've helped a few authors get set up with their own websites, and the same concerns translated. They cared very much about how the site appeared, and had intelligent opinions about why that was the case. They weren't web ingenues -- they'd been reading other author blogs for years. Why would their concern with the appearance of the written word change when that word was online?

I can't name names, but these authors were far from self-publishing. They had substantial contracts from major houses. Their books were all covered in the NYTRB. The publisher of course paid for one lay-out of the book, but it was not customary to cover three. That's why the author used his personal funds -- for the extra two lay-outs.

qznc4• 13 years ago

For my inner web designer this reads like "I want to see my blog in three different themes". Cost: A few minutes.

mwilliamson• 13 years ago

I used to be a developer for some technical websites (publishing articles, blogs, newsletters, that sort of thing), mainly around SQL Server and .NET. Almost all of the authors used Microsoft Word, the main value being familiarity and using Track Changes. I came to appreciate Track Changes when I wrote or edited the occasional article, and I can't imagine it would be easy to find a replacement for the functionality that would work smoothly enough to justify convincing all the authors and editors to switch. Fortunately, the authors and editors were pretty good about using the house style in Word, meaning that the articles were semantically marked up. I wrote a converter that did a pretty good job of generating clean HTML from the source Word, mainly by mapping Word styles to the corresponding pieces of HTML.

One of the more interesting challenges was the mismatch between the structure of Word docx files and HTML. Whereas HTML has plenty of nesting, docx files have a comparatively flat structure. For instance, suppose you want a nested list of depth 2 that looks like this:

    * Outer
        * Inner

One way a docx (XML) file can represent this is a paragraph element with the style "Bullet1" (and the text "Outer"), followed by a paragraph element with the style "Bullet2" (and the text "Inner"). The two elements are completely separate, and you have to infer that they're part of the same list, and that the second bullet is the child of the first. Once you've done that, you can generate the corresponding HTML, which has the inner list as a child of the outer list element.

If anybody's interested, I wrote a Word to HTML converter for node.js using the same ideas: https://github.com/mwilliamson/mammoth.js

guynamedloren3• 13 years ago

This was a bit difficult to follow, but if it says what I think it says, markdown is a step in the right direction for device-agnostic content. With markdown, the content creator is not responsible for design and layout - this is handled independently by a designer, or several designers, with different designs for different outputs (desktop, mobile, pdf, ePub, etc). One major upside to markdown is that it can be written in any text editor on any device - from desktop software (notepad) to forms in a browser. Another upside is uniformity - with multiple writers collaborating on content, or if a specific style should be followed, there's little to no possibility for deviation - just write some '##' for headers and '-' for lists and the output always looks uniform.

The problem is that there is a learning curve to markdown, and while it's a small learning curve, it's still a hurdle. Toolbars and pseudo-WYSIWYG editors that output markdown are good baby steps. Fortunately, it's becoming more commonplace and picking up steam outside of developers with integration on sites like Reddit.

ams6110• 13 years ago

There is really no more difficulty in learning Markdown than there is difficulty in learning how to avoid all the baffling, un-undo-able ways that most rich text boxes can completely stuff up the formatting of your content, to the point where you simply have to wipe it all out and start over.

andrewflnr2• 13 years ago

Objectively, Markdown isn't hard to learn, but people don't really want to learn anything, they just want to look for the button. Discoverability is, for most people, an important advantage of GUIs over most interpretation-of-freeform-text interfaces (like command lines and programming or formatting languages).

johnjlocke• 13 years ago

Markdown isn't difficult for us; it is a very real hurdle for those who are left in charge of content management.

bambax• 13 years ago

At many companies that I've worked with, content creators (authors) write in Word, and then content managers/editors copy-paste from Word into a CMS, losing part or all of the formatting in the process.

I once developed a specific transformation engine to convert Word documents to a given schema -- if they respect a set of rules that the transformation engine enforces.

Authors will always want to use Word; what would be interesting would be a generic tool to avoid the copy-and-paste step, but the "genericity" part is very hard...

Short of this, I built a small utility that converts rich text to Markdown: http://markitdown.medusis.com

It can be used to copy-paste from Word (or any rich text) and retains all formatting that core Markdown supports; it runs in the browser, locally (no roundtrip to any server) so no one should be able to see the content you use it for.

dools11• 13 years ago

I really don't think that markdown solves the wysiwyg problem. People need to be able to see precisely how the content will appear on the page as they enter it and in a way that they can't possible break, because if they can, they will. Check out our demo here and tell me whay you think: http://www.decalcms.com/tour/

guynamedloren3• 13 years ago

Looks cool, but what about being device agnostic?

drcongo• 13 years ago

You should post that link a few more times in case anyone else has missed it in previous replies.

smoyer• 13 years ago

I clicked on this link due to the simply awesome title, but realized the author had a great point. When asking "how does this look" what we really mean is "is this rendering the way I want". He posits that to properly answer this question, you must ask "on what", but my feeling is that you need to split the question into textual formatting (which can stay the same on all devices) and layout (which might be adjusted for the device).

In the old days (yes ... I'm old), we used WordStar on CP/M and we were careful to use our limited formatting features to maximize the impact of our words. We had bold, underline and (sometimes) even italics. When we composed our text, we assumed we'd use 55 of the 66 lines on the paper, and 75-80 characters across the page (depending on margins). We did this because that's what a 12 CPI typewriter would do. If we moved to a different printer, it might not be able to produce the exact same document, but with a few exceptions, we could live with the changes to the line wrapping and simply print it.

The problem introduced to printing when laser printers arrived (yes ... you could do cheesy images on dot-matrix printers) was that we now had to flow around images, account for multiple text sizes and pitches. As the web matured, we never quite completely separated the text formatting from the layout. My recommendation is that you focus on the formatting of your text when writing. Let the designer figure out how the layout needs to change when "responsive design calls".

shortformblog2• 13 years ago

This issue is been one I've been thinking about a lot lately—at least from the writer's perspective.

The office I work in is a very heavy copy-driven office, with multiple publications and multiple clients. You can tell how old a Web-based client is based on the way it handles copy flow. The oldest one relies on Microsoft Word; my program relies on a workflow using Markdown and Editorially—one I've advocated for elsewhere. The reason the older program is sticking with Word is not because the writers and web editors prefer it; rather, the copy editor prefers Word because of its track-changes functionality. It "just works" for them.

But ultimately, it's causing major issues for the web editors, because they have to put in a lot of extra work to add in links and formatting. It's a waste of everyone's time to deal with extra workflow with a product designed for a medium many people are no longer even writing for. Which is why I've made an effort to find alternatives to Word for our Web properties.

We need to write flexibly in the internet age; Word complicates and adds extra steps to a medium where good ideas need to be organized, quickly. I don't want my writers to have to worry about extra steps or formatting—I want them to write good stories.

That's why I use Markdown. It's why I sell my co-workers on writing in Mou and editing in Editorially. We do not have to stand for an outdated system. We can improve it, step by step.

We no longer need to print or typeset our content. We need to start acting like there's nothing standing in our way besides good writing and editing.

guynamedloren3• 13 years ago

Would love to talk to you about a project I'm working on. It's similar to Editorially, so as an Editorially user I'd appreciate your thoughts and feedback on the direction I'm headed. Can I email you?

shortformblog2• 13 years ago

Sure — I have an email address listed on my blog, http://shortformblog.com/. I check it regularly. Thanks!

hyperion20102• 13 years ago

There seems to me that there is a solution to this on the web and perhaps elsewhere (scientific publishing comes to mind for me).

We need to segregate data from presentation. More importantly we need to give users a choice in how their data is presented instead of forcing a particular design or presentation of the content on them.

If a user can choose how they want to read an article (tablet? desktop with lines of text that run the full width of the screen? phone? terminal window?) we should let them and give them options. There is no best way to present data because users are not all the same robotic machine, some prefer one format some prefer another. There is no universal best.

Why can't I read HN's content using reddit's design? Maybe I can and I haven't tried. My point is that most of the content we consume on the internet is text, pictures and video. I hate the youtube interface. Why the hell can't someone write a better one and then I view youtube's data that way?

Dissociate the front end from the backend. Send all the interface designers off to design frontends for any website that with a certain kind of data. Let the user pick which frontends they want for which website and then the website can send the data. Compensate the the frontend designer by giving them a portion of the revenue or something, or have users pay a little bit for frontends on an app store or something, or have websites pay the designer of the most effective frontend to use it as the default for users who don't bother to choose their own frontend(smarter people than me can figure out how to monetize this).

Am I insane to think that for a huge portion of the content on the web data and presentation can be completely segregated? Text is text, pictures are pictures, figures in papers are figures. Sure, a data person might insist that their data must be presented in a certain way, but isn't that just saying "fuck the user I'm and artist?"

What would it take for a system like this to become reality? (in scientific publishing what it would take is publishers releaseing the raw xml versions of the paper--which they already have--and it would make stuff like citations a thousand million times easier to deal with)

OvidNaso• 13 years ago

For desktop, there is Stylish. Write your own CSS.

https://addons.mozilla.org/en-US/firefox/addon/stylish/

minor_nitwit2• 13 years ago

Most sites have segregated data from presentation. The problem would be your second point - that it's not exposed as being user controllable. It is in fact user controllable through scripting in most cases, but it's not surfaced in any way.

Right in my browser, firefox, and maybe yours, I can set the default fonts, sizes, and colors, and I can force sites to use my settings. This is a partial step towards where you're going. Most designers will not simply use the foreground, background, serif, and sans-serif fonts that a user has set. This could be a good thing, since the majority of people don't even know that these options exists, but it is forcing a single design upon the users.

smacktoward3• 13 years ago

What would it take for a system like this to become reality?

It already is a reality. If you want to divorce content completely from presentation, you can do that right now, today, with HTML & CSS. There's no technical hurdle stopping you.

The problem is that understanding that "content" and "presentation" are two separate things requires people to work at a level of abstraction that most of them are not used to working at. In the tools they're familiar with, it's all mashed together. (You can separate the two in Word with things like document styles, but that's not how Word works by default; and there's little practical benefit to doing so for small documents anyway, so few people discover it unless a more advanced user takes the time to teach them.) So when you try to teach them to do their work in this new way, it feels to them like you're just adding unnecessary complications to their workflow. They then reject your tools as pointless egghead stuff, and you for trying to foist them on them.

It's a cultural problem, in other words, not a technical problem.

Chris_Newton• 13 years ago

We need to segregate data from presentation.

Sorry, but I don’t buy that. The very best presentation is almost always customised to the material it conveys.

We try to separate content and presentation as a compromise, partly because it’s too labour-intensive to craft a bespoke presentation for every little job, and partly to separate skill sets because someone can be a great author but suck at design. But it’s still a compromise, and someone who both knows their material and knows design will often be able to create a more effective presentation of that material than they could if they were constrained to some pre-determined, standardised box of presentation tools.

By the same principle, it’s not necessarily an advantage to let someone viewing that content customise the design arbitrarily, because it’s almost axiomatic that such a person isn’t yet an expert on the material. They don’t know which ideas are the important ones that the author wants to build on, or which relationships in the data are the most enlightening ones to explore. A well made presentation, created by or in collaboration with a subject matter expert, can direct the viewer through the material in a more considered way.

To me, it makes no more sense to use a medium where the viewer has to make presentation choices than it does to send them a few spreadsheets of raw data and let them write their own content or plot their own charts.

hyperion20102• 13 years ago

Let me rephrase my original statement. We need to segregate data from a single format/layout.

I do not think the analogy to spreadsheets applies here. There are (at least) thousands of perspectives on/presentations of scientific data that are completely meaningless. In that case the perspective and presentation matters (though the sharing the original data opens up the opportunity for others to find new perspectives as well, though at the moment they do need to 'plot their own charts')

That said, once the author has chosen the perspective that perspective will be conveyed via some medium. At that point the data should be able to stand on its own. I used the word presentation, but 'layout' is probably closer to what I meant. If we take my use of presentation literally then we agree and this is why someone posting slides for a talk without also posting the talk is a terrible idea.

With regard to expertise, I would argue that everyone is an expert on what format/layout they find easier to use (sort of like why we let people move their windows around in a window manager instead of forcing them all full screen, re: tablets are major offenders here). I'm not talking about letting people change the words here or put the legend for figure 1 with the data for figure 3.

guido4000• 13 years ago

Maybe you want to try this Angular YouTube interface http://toogl.es/

DigitalJack• 13 years ago

I couldn't even tell what argument the author was trying to make. The post seemed to be complaining about people using Word to write content. Then later on suggesting a CMS should be discrete applications. Isn't Word a discrete application?

sjwright• 13 years ago

The argument is that Word isn't a discrete application, it's trying to do everything, and teaching people that they can do anything.

justinph• 13 years ago

Inline editing makes perfect sense if the only thing you ever publish to or plan to publish to is the web.

Many large organizations do more than that. Apps, feeds, radio, print, eBooks. There's more than just the web.

Inline editing privileges one of these over the other, which can be a misnomer. Making editing on the web is great, but we need to be careful that our tools aren't too closely coupled to web display where inappropriate.

8ig8• 13 years ago

Maybe we just need to wait this one out? The problem is due to the fact that the current batch of content creators/managers learned text entry on word processors, but that must be changing. I'm guessing word processors had to shake of the legacy of the typewriter. Now we need to slowly shake off the legacy of the desktop word processor.

yen223• 13 years ago

How are kids currently writing their documents? I suspect Microsoft Word will be with us for a very long time.

InclinedPlane• 13 years ago

The problem with WYSIWYG is that it solves the wrong problem. Sure, what you see is what you are going to see, but that's irrelevant. What you care about is being able to change what you see. And that is tied up with all sorts of invisible context that you can't see.

Good interfaces tend to be based around the principle of least surprise. But in a typical WYSIWYG editor it is commonplace to be in a situation where you don't know what will be produced when you press a key or press enter. The purpose of tools is to bring complex problems under control. To make a bridge between the underlying problem space and a set of controls that are intuitive for a user. WYSIWYG does a poor job of doing that.

dools11• 13 years ago

This is exactly the problem we're solving at http://www.decalcms.com/tour/ what do you think?

chmike• 13 years ago

It's the fourth comment of you referring your cms tour. This looks like spam to me.

ChuckMcM2• 13 years ago

One of my least favorite things about markdown:

      There are three spaces * for content people – not creators,
      because not all content people create loads of content. Some just
      manage it – push it from here to there. Those places are:

   1. A space for writing. For writing and structuring.
   2. A space for management. For adding meta data, workflow, 
      configuration and managing roles and people.
   3. The website space. Basically your website. A place where 
      you begin the access user journey. Or preview your content.
      Generally the starting points for lots of little 
      administration tasks.

See how the numbers sit outside the left margin? Or worse you've styled paragraphs and MD has chosen that your list elements need to be wrapped in p /p pairs and suddenly your bullets or numbers are sitting all alone while your paragraphs race over to the right margin.

I've beat upon the perl code a bit but tracking down the 'paragraphify' bit is stuck in a regex pulling stuff apart. In my custom version I attach a different style to paragraphs in lists than ones in the document. This helps but there are still edge cases that are very annoying.

bbx• 13 years ago

Actually, the HTML code shows an <ol> for that list. It's not related to markdown (which in this case rendered the appropriate HTML code). The numbers (or bullets) being displayed in the left margin is just a browser's default styling. It increases vertical readibility, considering that lists items are meant to be read in sequence.

You can change it via CSS. Just add to your <ol> or <ul> the following: list-style-position: inside. The numbers/bullets consequently become part of the text.

My preference for styling lists is to leave the numbers/bullets outside but apply a margin-left to the lists so that its numbers/bullets fit inside the main wrap.

andrewingram• 13 years ago

Hanging bullets/numerals have nothing to do with markdown, they're a typographic choice and in my opinion look better than the indented style that you normally get by default.

In fact, the author of the post has previously written a hugely popular series about typography that specifically mentions this choice: http://www.markboulton.co.uk/journal/five-simple-steps-to-be...

ChuckMcM2• 13 years ago

Thanks for the link, I stand corrected that the OP wants that behavior in his output. To be honest that is so far out of my expectation for that typographic choice that I never once considered it a 'desired feature.' So there ya go.

chris_wot• 13 years ago

Here's a serious question: what exactly is a "content person" when they clearly don't create content? According to the article, they push data from A to B.

Surely that is the problem? Wouldn't the truly disruptive question be "How do I automate those who push content from point A to point B"?

dools11• 13 years ago

This is precisely the problem we're solving with http://www.decalcms.com/ ... I'd love to hear your feedback!

epo• 13 years ago

You want some feedback? STFU! This is the fourth time you've pimped your project on this page. Give it a rest.

masukomi• 13 years ago

um... can anyone here define "WYSIWTFFTWOMG"? What You See Is What The Fuck For The Win Oh My God ... is the closest I can come and it makes no sense.

Wysiwtfftwomg

Related Stories