5 ms·

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 pr

by 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?!

by bcoates 13y ago

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?!