Rethinking WYSIWYG
-
Word processors such as Microsoft Word are said to be WYSIWYG: what you see is what you get. In a sense that’s true, but in another sense markup languages such as HTML or LaTeX are really WYSIWYG.
Text files are simpler because there are no mysterious forces at work.
-
Word processors such as Microsoft Word are said to be WYSIWYG: what you see is what you get. In a sense that’s true, but in another sense markup languages such as HTML or LaTeX are really WYSIWYG.
Text files are simpler because there are no mysterious forces at work.
TL;DR: for text files, notepad is WYSIWIG. For a completely useless definition of WYSIWIG. I might be monday-morning-dense, but what'st the point?
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
TL;DR: for text files, notepad is WYSIWIG. For a completely useless definition of WYSIWIG. I might be monday-morning-dense, but what'st the point?
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchypeterchen wrote:
for text files, notepad is WYSIWIG
For executables, blue screen of death is WYSIWIG. Yes, there is no point.
-
TL;DR: for text files, notepad is WYSIWIG. For a completely useless definition of WYSIWIG. I might be monday-morning-dense, but what'st the point?
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyI think the point was that proprietary wysiwyg editors like Word interject an intermediary layer to do their magic that work fine for most users... until they don't. I've had Word docs corrupted or choke on some formatting and there's no easy way to figure out how or why it's that way. And how to fix it. That's well and fine for most people most of the time. Text files work better (in some ways) if you know what you're doing (HTML or Markdown or LaTeX or...) and the "what you see" is as important as the "what you get". Ever seen the HTML output from Word? Can you imagine what's happening inside the DOC/DOCX file? Yikes. Back in the day we used FrameMaker for publishing and even though we did most work in the wysiwyg editor, the text-based file format was a blessing for troubleshooting problems. There's also the concept - which I subscribe to - that many features wysiwyg editors give us are extraneous to the content and complicate more than they help. Plain text, Markdown, simple HTML markup make for more portable files, more focus on the content and, these days, can be easily and quickly parsed for fancier presentation formats (web pages, HTML/CSS slides, etc.) when necessary.
Director of Content Development, The Code Project
-
Word processors such as Microsoft Word are said to be WYSIWYG: what you see is what you get. In a sense that’s true, but in another sense markup languages such as HTML or LaTeX are really WYSIWYG.
Text files are simpler because there are no mysterious forces at work.
I like the part where the article deteriorates into a discussion of the meaning of the word "get." What you see is what you get... if "get" means "print." It can be revealing at times to take a bit of linguistic imprecision (like "what you get") and attack the preconceived notions that underlie it, e.g. "you're definitely going to print that Word document." This claim is not necessarily true, but as a result of WYSIWYG, people are basically using what would have passed for a "desktop publishing" app 20+ years ago to write their grocery lists and such. This is one instance of a sort of reverse Moore's Law, under which the storage requirements for a hypothetical bundle of real information double every year or so. Maybe creatively misunderstanding the word "get" is the sort of mental trick that underlies this growth.
-
I think the point was that proprietary wysiwyg editors like Word interject an intermediary layer to do their magic that work fine for most users... until they don't. I've had Word docs corrupted or choke on some formatting and there's no easy way to figure out how or why it's that way. And how to fix it. That's well and fine for most people most of the time. Text files work better (in some ways) if you know what you're doing (HTML or Markdown or LaTeX or...) and the "what you see" is as important as the "what you get". Ever seen the HTML output from Word? Can you imagine what's happening inside the DOC/DOCX file? Yikes. Back in the day we used FrameMaker for publishing and even though we did most work in the wysiwyg editor, the text-based file format was a blessing for troubleshooting problems. There's also the concept - which I subscribe to - that many features wysiwyg editors give us are extraneous to the content and complicate more than they help. Plain text, Markdown, simple HTML markup make for more portable files, more focus on the content and, these days, can be easily and quickly parsed for fancier presentation formats (web pages, HTML/CSS slides, etc.) when necessary.
Director of Content Development, The Code Project
OK, that starts to make some sense.
Terrence Dorsey wrote:
Ever seen the HTML output from Word?
Yes, and I've been around when WYSIWIG became a distinguishing feature. For me, at the heart of WYSIWIG, is the user interacting with the result itself: e.g. instead of a list of picture names and subtitles and format instructions, they are interacting with a photo album. It *removes* the user interface from perception: instead of clicking a button that makes the text bigger, they make the text bigger. Of course, all abstractions are leaky (or, as D.A. said it, "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair"). So yes, being able to delve down can be a life saver. In the end, tghe real life analogy is also limiting - which isn't always bad, humans like handrails. It might help focusing on the really important stuff, like finding a funny title for the 57th picture of Jon and Kiran pouting.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
OK, that starts to make some sense.
Terrence Dorsey wrote:
Ever seen the HTML output from Word?
Yes, and I've been around when WYSIWIG became a distinguishing feature. For me, at the heart of WYSIWIG, is the user interacting with the result itself: e.g. instead of a list of picture names and subtitles and format instructions, they are interacting with a photo album. It *removes* the user interface from perception: instead of clicking a button that makes the text bigger, they make the text bigger. Of course, all abstractions are leaky (or, as D.A. said it, "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair"). So yes, being able to delve down can be a life saver. In the end, tghe real life analogy is also limiting - which isn't always bad, humans like handrails. It might help focusing on the really important stuff, like finding a funny title for the 57th picture of Jon and Kiran pouting.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyIt also occurs to me that we see the circle complete itself again with tools like jsFiddle[^] or Multimarkdown Composer[^], which blur the line between code, markup and WYSIWYG. Or even IDEs that autocomplete your code right down to the semicolon.
Quote:
Yes, and I've been around when WYSIWIG became a distinguishing feature.
Indeed, I recall doing my writing and markup in WordPerfect and handing off to the desktop publishers for formatting. Man, I dreamed of better WYSIWYG tools. And they arrived, after a fashion. But all the WYSIWYG features in the world don't make page layout in Word any less soul-destroying. And now I find myself back in a (slightly more sophisticated) text editor, handing off to publishing tools only when necessary. What's old is new again. (And what an interesting discussion sparked by such a poorly written post!)
Director of Content Development, The Code Project
