Wysiwyg Editor

[Channing Arther]

Incomputing, WYSIWYG (/ˈwɪziwɪɡ/ WIZ-ee-wig), an acronym for what you see is what you get,[1] refers to software that allows content to be edited in a form that resembles its appearance when printed or displayed as a finished product,[2] such as a printed document, web page, or slide presentation. WYSIWYG implies a user interface that allows the user to view something very similar to the result while the document is being created.[3] In general, WYSIWYG implies the ability to directly manipulate the layout of a document without having to type or remember names of layout commands.[4]

Before the adoption of WYSIWYG techniques, text appeared in editors using the system standard typeface and style with little indication of layout (margins, spacing, etc.). Users were required to enter special non-printing control codes (now referred to as markup code tags) to indicate that some text should be in boldface, italics, or a different typeface or size. In this environment there was very little distinction between text editors and word processors.

These applications typically used an arbitrary markup language to define the codes/tags. Each program had its own special way to format a document, and it was a difficult and time-consuming process to change from one word processor to another.

The use of markup tags and codes remains popular today in some applications due to their ability to store complex formatting information. When the tags are made visible in the editor, however, they occupy space in the unformatted text, and as a result can disrupt the desired layout and flow.

By 1981, MicroPro advertised that its WordStar word processor had WYSIWYG,[9] but its display was limited to displaying styled text in WYSIWYG fashion; bold and italic text would be represented on screen, instead of being surrounded by tags or special control characters.[10] In 1983, the Weekly Reader advertised its Stickybear educational software with the slogan "what you see is what you get", with photographs of its Apple II graphics,[11] but home computers of the 1970s and early 1980s lacked the sophisticated graphics capabilities necessary to display WYSIWYG documents, meaning that such applications were usually confined to limited-purpose, high-end workstations (such as the IBM Displaywriter System) that were too expensive for the general public to afford. As improving technology allowed the production of cheaper bitmapped displays, WYSIWYG software started to appear in more popular computers, including LisaWrite for the Apple Lisa, released in 1983, and MacWrite for the Apple Macintosh, released in 1984.[12]

The Apple Macintosh system was originally designed so that the screen resolution and the resolution of the ImageWriter dot-matrix printers sold by Apple were easily scaled: 72 PPI for the screen and 144 DPI for the printers. Thus, the scale and dimensions of the on-screen display in programs such as MacWrite and MacPaint were easily translated to the printed output. If the paper were held up to the screen, the printed image would be the same size as the on-screen image, but at twice the resolution. As the ImageWriter was the only model of printer physically compatible with the Macintosh printer port, this created an effective closed system. Later, when Macs using external displays became available, the resolution was fixed to the size of the screen to achieve 72 DPI. These resolutions often differed from the VGA-standard resolutions common in the PC world at the time. Thus, while a Macintosh 15-inch (38 cm) monitor had the same 640 480 resolution as a PC, a 16-inch (41 cm) screen would be fixed at 832 624 rather than the 800 600 resolution used by PCs. With the introduction of third-party dot-matrix printers as well as laser printers and multisync monitors, resolutions deviated from even multiples of the screen resolution, making true WYSIWYG harder to achieve.[13]

The phrase "what you see is what you get", from which the acronym derives, was a catchphrase popularized by Flip Wilson's drag persona Geraldine, first appearing in September 1969, then regularly in the early 1970s on The Flip Wilson Show. The phrase was a statement demanding acceptance of Geraldine's entire personality and appearance.

For the record, I don't use Joplin to write code, or css, or anything. Just formatted notes. I just really hate these formatting issues. And I often use Typora to edit Joplin notes - it's basically a mix between WYSIWYG and plain Markdown entry, which works quite well for me. You can enter MD, but as soon as you finish typing a tag, the formatting is rendered in-place, so there are no two editor windows. And there's WYSIWYG buttons and context menus as well. (Not sure how it handles quotes, though. I don't particularly want anything but the plain, symmetric, vanilla quotes, and often turn related features off.)

Hi maybe an other suggestion could be a mix of WYSWYG and plain markdown code like it is handeld in the editor from ghostwriter or in marktext.

In addition marktext is also a JavaScript application. So maybe @laurent you would like to have a look at the code.

So if you find a solution to implement the behavior of Marktext, please add it to the plain WYSIWYM editor, do not replace it.

The other part of my reflection is pedagogical. What is the point of using markdown without learning markdown?

Joplin is a note taking app with its primary focus on notes and being able to sync between several different OS and devices while using your own cloud system.

If you want a text processor, use Word or some other crap. Notes are usually text. For people who like to style their text, there's markdown that renders text into something more presentable.

Why do you think that professional typesetting is done in LaTeX and not some shitty WYSIWYG word processor?

For my part I seriously dislike anything that includes invisible format and styling markers, like WYSIWYG word processors. But that's a personal choice. If a WYSIWYG editor ever made it into Joplin, I would only hope it's a choice and not mandatory.

Recently I spoke at the Highland Fling Conference in Edinburgh and, as part of my presentation on Choosing the right Content Management System, I had a bit of a rant about the use of WYSIWYG editors in Content Management Systems. I think these things are responsible for not only a lot of badly formatted content, but also for holding back the development of better ways of allowing non-technical users to deliver content.

WYSIWYG Editors suck because they promote thinking about style rather than content. While content editors are busy changing headings to Comic Sans, pondering the use of a grimacing smiley on their about us page or getting creative with colour, they are not considering the actual copy they are adding to the site.

WYSIWYG Editors suck because as a designer you lose control over big chunks of the design. Anywhere that allows people to enter HTML via an editor allows them to get as creative as they like, using any mark-up that they like. Unless you carefully go through and remove all the creativity that stuff is going to stay there. For developers, even if you switch off most of the buttons, just allowing the administrator to enter simple formatting and links, you still have a situation where a user is entering HTML which you then display on the website. This can enable all kinds of stuff to get into your content, which is then very hard to remove and fundamentally tied to the current design of the site.

We need a new kind of content editing tool. In Perch the default editor we use is MarkItUp with Textile formatting enabled. Textile is pretty simple to learn and MarkItUP means that users can select a bit of text and hit the bold button which will then wrap it correctly so when the form is submitted Perch transforms it into HTML strong elements.

The administrator has access to just a few simple tools for adding formatting, and the formatting is related to the content and not the design of the site. If it is correct for content to be emphasised that should remain the same after a redesign or if the content is used elsewhere other than on the site.

I really like the way the new Campaign Monitor editor works; editing within the context of the template, which I imagine returns to the editorial emphasis to content rather than style. Much closer to actual WYSIWYG too!

For me, MarkDown does everything I need and it would most definitely be my choice when writing blog posts, replying to support calls or writing KBs. If I want to get created I can just stick HTML in the post. Otherwise, the MarkDown syntax is much clearer to read and edit.

@Ben Bodian in context editing like this works well for simple stuff, however it is not without problems. See this post from Drew McLellan (my partner in life, business and web-related grumbling) on the subject: -lure-of-on-page-editing

One of the options you might want to investigate is something I got a brief demo of when I went to some level 1 Umbraco ( ) training a few months back and that is the integration between Windows Live Writer and Umbraco and it allows the client to basically use Live Writer as their wysiwyg editor and when it posts to Umbraco, their funky inline styles, rotated images etc are magically converted to valid HTML.

Of course if the website editor were approaching their content creation task with due care, they would check the published page (or a preview if your CMS provides that) and see the mistakes, read the documentation to learn how to correct them, and fix them.

Regarding the second problem, I implemented a solution much like Ben Callahan suggests above for a couple clients using our preferred CMS, ExpressionEngine. I wrote up a detailed explanation of how I did this here. Make adding inline images to ExpressionEngine entries safe and easy for your clients

Of course as Rachel alluded to in her article, there are those writers who see all these nifty WYSIWYG tools and spend their time playing around with fonts and colours and as a result both the design and content suffer.

3a8082e126