7 ms·

Wysiwtfftwomg

131 points by Isofarro 13y ago

bcoates 13y 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.
- qznc 13y 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?
  - minor_nitwit 13y 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.
  - bcoates 13y 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.
    - aaronem 13y ago
      I'm not sure I agree on your last point; some of the younger, less print-bound designers I've worked with have a good understanding of the difference between presentation and semantics, and have been often enough annoyed by sites which look just dandy at 1920x1080, but are unusable on a phone, to have a burning desire not to produce more of the same. Stipulating that point, though, perhaps the solution is to keep designers at a higher level of granularity -- to have them produce designs for "large screen", "small screen", "mobile", "print", &c., including general ideas of how body text shall appear, but leave the more granular detail to someone who's not so much wedded to pixel-perfection, but instead understands that the same content will necessarily look different when differently rendered, and who can understand and accommodate those differences to produce a result that works well across all of them.
    - qznc 13y ago
      Then there is also retina vs non-retina displays, the next site redesign, glossy vs matte screens, and non-color calibrated displays. Then there are different browsers, operating systems, and fonts installed. It is almost as funny as the request that a logo must use the "Pantone 1337" color. It probably is not representable in RGB and nobody has a color-calibrated screen.
  - dools 13y 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/ http://www.decalcms.com/tour/
- jonhohle 13y 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.
  - qznc 13y ago
    Nice story, but the important part is missing: Did it work? Did people accept that? Is it already replaced by something else now?
- 3pt14159 13y 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 13y 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.
    - 3pt14159 13y ago
      At first I thought like you, until I started to deal with embed issues. For italics, bolding, and images, it works OK. Shitty to deal with handling some keyboard inputs, but not terrible. Beyond that, it is unmanageable though.
  - dools 13y 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/ http://www.decalcms.com/tour/
    - 3pt14159 13y ago
      It's good, but it lacks some features I want, like embeding youtube videos and allowing an arbitrary number of line breaks. But it is good and you should be very proud of it. I know how hard it is to make something this complex with contenteditable.
      - dools 13y ago
- edwinyzh 13y ago
  Wow! This almost exactly what I feel about html editor and why I'm working my live html/css editor (http://liveditor.com http://liveditor.com) ! Can I quote your response somewhere on my website to explain the idea of LIVEditor?!
the1 13y 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.
cabirum 13y 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_tables http://en.wikipedia.org/wiki/Help:Table/Introduction_to_tabl... [2]: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#wiki-tables https://github.com/adam-p/markdown-here/wiki/Markdown-Cheats...
- egeozcan 13y 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/ http://madebymany.github.io/sir-trevor-js/
  - cabirum 13y 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.
  - dools 13y 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/ http://www.decalcms.com/tour/ what do you think?
    - egeozcan 13y ago
      I've seen and even worked with some examples of this approach earlier. It works well when you have definitive templates that all the content would fit but you return to the step 1 when you need a flexible white box for the user to fill.
overshard 13y 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?
- egeozcan 13y 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 13y 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.
deleted 13y ago
[deleted]
mikecane 13y 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 13y 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 13y 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 13y 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"?
- smacktoward 13y 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?"
- dools 13y 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/ http://www.decalcms.com/tour/ what do you think?
DanI-S 13y 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 13y 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-recovery/ https://addons.mozilla.org/En-us/firefox/addon/lazarus-form-... Chrome: https://chrome.google.com/webstore/detail/lazarus-form-recovery/loljledaigphbcpfhfmgopdkppkifgno?hl=en https://chrome.google.com/webstore/detail/lazarus-form-recov... Safari: http://getlazarus.com/download http://getlazarus.com/download
  - LordIllidan 13y 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 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 13y ago
  Unknown or expired link.
Samuel_Michon 13y 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).
- smacktoward 13y 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.
- Hemospectrum 13y 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.
curveship 13y 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?
- qznc 13y ago
  For my inner web designer this reads like "I want to see my blog in three different themes". Cost: A few minutes.
- Samuel_Michon 13y 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.
  - curveship 13y 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.
deleted 13y ago
[deleted]
mwilliamson 13y 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 https://github.com/mwilliamson/mammoth.js
guynamedloren 13y 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 13y 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.
  - andrewflnr 13y 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 13y ago
    Markdown isn't difficult for us; it is a very real hurdle for those who are left in charge of content management.
- bambax 13y ago
smoyer 13y 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".
shortformblog 13y 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.
- guynamedloren 13y 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?
  - shortformblog 13y ago
    Sure — I have an email address listed on my blog, http://shortformblog.com/ http://shortformblog.com/. I check it regularly. Thanks!
hyperion2010 13y 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)
- smacktoward 13y 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.
DigitalJack 13y 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 13y 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 13y 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 13y 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 13y ago
  How are kids currently writing their documents? I suspect Microsoft Word will be with us for a very long time.
InclinedPlane 13y 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.
- dools 13y ago
  This is exactly the problem we're solving at http://www.decalcms.com/tour/ http://www.decalcms.com/tour/ what do you think?
  - chmike 13y ago
    It's the fourth comment of you referring your cms tour. This looks like spam to me.
    - dools 13y ago
      Seven, actually.
ChuckMcM 13y 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 13y 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 13y 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-better-typography-part-2 http://www.markboulton.co.uk/journal/five-simple-steps-to-be...
chris_wot 13y 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"?
dools 13y ago
This is precisely the problem we're solving with http://www.decalcms.com/ http://www.decalcms.com/ ... I'd love to hear your feedback!
- epo 13y ago
  You want some feedback? STFU! This is the fourth time you've pimped your project on this page. Give it a rest.
masukomi 13y 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.

131 points by Isofarro 13y 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.

qznc 13y 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?
- minor_nitwit 13y 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.
- bcoates 13y 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.
  - aaronem 13y ago
    I'm not sure I agree on your last point; some of the younger, less print-bound designers I've worked with have a good understanding of the difference between presentation and semantics, and have been often enough annoyed by sites which look just dandy at 1920x1080, but are unusable on a phone, to have a burning desire not to produce more of the same. Stipulating that point, though, perhaps the solution is to keep designers at a higher level of granularity -- to have them produce designs for "large screen", "small screen", "mobile", "print", &c., including general ideas of how body text shall appear, but leave the more granular detail to someone who's not so much wedded to pixel-perfection, but instead understands that the same content will necessarily look different when differently rendered, and who can understand and accommodate those differences to produce a result that works well across all of them.
  - qznc 13y ago
    Then there is also retina vs non-retina displays, the next site redesign, glossy vs matte screens, and non-color calibrated displays. Then there are different browsers, operating systems, and fonts installed. It is almost as funny as the request that a logo must use the "Pantone 1337" color. It probably is not representable in RGB and nobody has a color-calibrated screen.
- dools 13y 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/ http://www.decalcms.com/tour/
jonhohle 13y 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.
- qznc 13y ago
  Nice story, but the important part is missing: Did it work? Did people accept that? Is it already replaced by something else now?
3pt14159 13y 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 13y 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.
  - 3pt14159 13y ago
    At first I thought like you, until I started to deal with embed issues. For italics, bolding, and images, it works OK. Shitty to deal with handling some keyboard inputs, but not terrible. Beyond that, it is unmanageable though.
- dools 13y 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/ http://www.decalcms.com/tour/
  - 3pt14159 13y ago
    It's good, but it lacks some features I want, like embeding youtube videos and allowing an arbitrary number of line breaks. But it is good and you should be very proud of it. I know how hard it is to make something this complex with contenteditable.
    - dools 13y ago
edwinyzh 13y ago
Wow! This almost exactly what I feel about html editor and why I'm working my live html/css editor (http://liveditor.com http://liveditor.com) ! Can I quote your response somewhere on my website to explain the idea of LIVEditor?!

the1 13y 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.

cabirum 13y 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_tables http://en.wikipedia.org/wiki/Help:Table/Introduction_to_tabl... [2]: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#wiki-tables https://github.com/adam-p/markdown-here/wiki/Markdown-Cheats...

egeozcan 13y 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/ http://madebymany.github.io/sir-trevor-js/
- cabirum 13y 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.
- dools 13y 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/ http://www.decalcms.com/tour/ what do you think?
  - egeozcan 13y ago
    I've seen and even worked with some examples of this approach earlier. It works well when you have definitive templates that all the content would fit but you return to the step 1 when you need a flexible white box for the user to fill.

overshard 13y 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?

egeozcan 13y 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 13y 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.

deleted 13y ago

[deleted]

mikecane 13y 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 13y 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 13y 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 13y 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"?

smacktoward 13y 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?"
dools 13y 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/ http://www.decalcms.com/tour/ what do you think?

DanI-S 13y 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 13y 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-recovery/ https://addons.mozilla.org/En-us/firefox/addon/lazarus-form-... Chrome: https://chrome.google.com/webstore/detail/lazarus-form-recovery/loljledaigphbcpfhfmgopdkppkifgno?hl=en https://chrome.google.com/webstore/detail/lazarus-form-recov... Safari: http://getlazarus.com/download http://getlazarus.com/download
- LordIllidan 13y 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 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 13y ago
Unknown or expired link.

Samuel_Michon 13y 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).

smacktoward 13y 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.
Hemospectrum 13y 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.

curveship 13y 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?

qznc 13y ago
For my inner web designer this reads like "I want to see my blog in three different themes". Cost: A few minutes.
Samuel_Michon 13y 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.
- curveship 13y 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.

deleted 13y ago

[deleted]

mwilliamson 13y 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 https://github.com/mwilliamson/mammoth.js

guynamedloren 13y 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 13y 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.
- andrewflnr 13y 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 13y ago
  Markdown isn't difficult for us; it is a very real hurdle for those who are left in charge of content management.
bambax 13y ago

smoyer 13y 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".

shortformblog 13y 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.

guynamedloren 13y 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?
- shortformblog 13y ago
  Sure — I have an email address listed on my blog, http://shortformblog.com/ http://shortformblog.com/. I check it regularly. Thanks!

hyperion2010 13y 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)

smacktoward 13y 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.

DigitalJack 13y 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 13y 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 13y 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 13y 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 13y ago
How are kids currently writing their documents? I suspect Microsoft Word will be with us for a very long time.

InclinedPlane 13y 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.

dools 13y ago
This is exactly the problem we're solving at http://www.decalcms.com/tour/ http://www.decalcms.com/tour/ what do you think?
- chmike 13y ago
  It's the fourth comment of you referring your cms tour. This looks like spam to me.
  - dools 13y ago
    Seven, actually.

ChuckMcM 13y 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 13y 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 13y 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-better-typography-part-2 http://www.markboulton.co.uk/journal/five-simple-steps-to-be...

chris_wot 13y 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"?

dools 13y ago

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

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

masukomi 13y 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.