6 ms·

Hacker culture and the fear of wysiwyg

51 points by jeswin 12y ago

mantrax5 12y ago
Uhmm. Ok, let's say you're Tour de France competitor, and you're told to use this: http://www.christydena.com/blog/wp-content/uploads/2010/02/trainingwheels.jpg http://www.christydena.com/blog/wp-content/uploads/2010/02/t... Is "fear" the correct word for your reaction? WYSIWYG is a good thing in predominantly visual programs (photo editing, vector illustrations, animation tools). WYSIWYG becomes a problem when the content being entered has semantics without explicit visual cues. By definition you can't have a "WYSIWYG" for semantical information, and if you give people a WYSIWYG HTML editor to enter content, they'll just tweak the code until it "looks" right, which will bomb when said content has to be transferred to a new medium (say, non-HTML). People may be liking Word, but the majority don't use it semantically, they just mash the font settings until the document looks approximately correct, never mind the document outline is a mess, because half their headlines are not headlines, but paragraphs with enlarged text.
- simias 12y ago
  You're right, I think the author has a point but putting it all under the umbrella of "WYSIWYG" is not helping it. For instance, I agree that the current mostly text-based interface to programming could be improved dramatically by abstracting ourselves away from the source files towards a more visual representation of the code, showing dependencies between functions etc... Syntax highlighting doesn't quite cut it. I wouldn't call that "WYSIWYG" at all though. In essence most source code is a graph of function calls and it's very hard to represent that in plain text. There have been some efforts in that direction (lately I remember the light table editor for instance) but at the end of the day I'm still editing ASCII files in emacs... What we need isn't WYSIWYG, it's better visual representation of the data we're manipulating.
  - markrages 12y ago
    I notice your response was in the form of a few paragraphs of text, rather than a photo or diagram. Most conversation are "text-based". Our human brains have hardware acceleration for text processing and we're quite good at it. Since programming environments exist to make the best impedance match between programmer and machine, they use text. Language uses incredible composability to encode great complexity. Flowcharts are one implementation of what you propose. Or LabView: http://www.ni.com/cms/images/devzone/pub/nrjsxmfm912163998723206173.jpg http://www.ni.com/cms/images/devzone/pub/nrjsxmfm91216399872...
    - TuringTest 12y ago
      Our human brains have hardware acceleration for image processing as well. Limiting ourselves to text is wasting half our natural resources. Flowcharts and LabView are old paradigms, they have and are problematic for abstract tasks (they're only good for data manipulation). What's needed is a new style of programming that combined the best of visual and textual representations. Wolfram Language [1] and Bret Victor's Inventing on Principle [2] are more modern approaches in that direction. [1] http://www.wolfram.com/language/ http://www.wolfram.com/language/ [2] http://vimeo.com/36579366 http://vimeo.com/36579366
    - simias 12y ago
      You'll also notice that while the comments are all plaintext, they're presented hierarchically as nested trees. There's also a hyperlink in your comment that I can follow easily, that's not plaintext. I'm not saying plaintext is bad, I'm just saying that we're not stuck with 80x25 green-on-black terminals anymore, there's room for improvement using our modern display capabilities.
      - mantrax5 12y ago
        Why yes, we're not stuck with 80x25 green on black terminals. Why even mention it? By the way that nested hierarchical tree is also written in text (HTML and CSS). So is the hyperlink. URLs? Text. Check any modern IDE and you'll see similar visualizations over text based source code. I can explore my project in a tree-based outline in my IDE. I can open my classes as an UML diagram. Turns out we're already in the future. Celebrate?
  - TuringTest 12y ago
    I think you've identified an interesting problem in the "cultural dialog" around this subject - that legacy terms like "WYSIWYG" and "Visual Programming" are holding back conversation. The core idea in the article (that "Hacker Culture’s bias is holding back interface design") is a solid one, but a new term would make it easier to identify the problem without all the implications carried out by the broken tools of old. Maybe some new term like "Rich Visual Interaction", or "Web Application IDEs", or anything that ties the idea of development with using modern visual technologies and representations would help.
- kijin 12y ago
  > By definition you can't have a "WYSIWYG" for semantical information, and if you give people a WYSIWYG HTML editor to enter content, they'll just tweak the code until it "looks" right, which will bomb when said content has to be transferred to a new medium (say, non-HTML). That problem can be mostly fixed with clever programming. Does the content seem to include a bunch of one-line paragraphs, all of which share roughly the same font that is different from the rest of the content? Treat them as headlines. Have a bit of tolerance for people who can't distinguish 13pt from 14pt, but if the sizes or other styling differ considerably, try to decide which ones are <h1> and which ones are <h2>, etc. Does the content include a bunch of consecutive paragraphs that begin with numerals (1. 2. 3.) or hyphens/asterisks? Turn them into <ol> and <ul> respectively. C'mon, even Microsoft Word knows how to do this, and the user can override it if the program guesses wrong. There's no reason why an open-source HTML editor can't do the same or better. You could even have the best of both worlds: the editor might recognize Markdown syntax and automatically convert them to the corresponding HTML markup for live preview. For example, if you begin and end a word with an underscore, put an <em> around it. (You can already configure Microsoft Word to do this.) If you begin a paragraph with ###, >, or four spaces, turn it into <h3>, <blockquote>, and <pre><code> respectively. Okay, but what if a piece of user-submitted content is so messed up that it is impossible to get any semantical information out of it? Well, think about it this way: whoever produced that content probably didn't intend to convey any semantical information anyway. By failing to determine the semantic structure of that content, the computer is actually guessing the author's intention correctly. Just slap a CSS normalizer on that piece of cow dung, and it will look more or less the same in all current and future browsers (which is probably what the author intended). The only thing that matters is that you don't produce such content. If someone else wants to shoot themselves in the balls with Comic Sans, why stop them? It's what they want. The primary reason why WYSIWYG editors carry a stigma is that the first generation of popular editors, such as TinyMCE and FCKEditor (the precursor to CKEditor), tended to produce horribly broken markup. But that was 10 years ago, and now we have much better editors. And we can make them even better if we want to.
asgard1024 12y ago
I think hackers (in any field) like "productive" user interfaces, everything else is irrelevant. There are productive WYSIWYGs and GUIs, look at e.g. Blender, but they are usually hard to learn and/or they look really ugly, so they are not appreciated by commoners or designers. For the UI to be productive, it has to have a couple of features: - Highly configurable, possibility of presets - Accessible only by keyboard - Available for scripting You can combine those with smooth learning curve and nice design, but it's very hard thing to do. That's why application builders (on either side) usually don't bother.
- anon4 12y ago
  > very hard thing to do That's pretty much the entire reason. Plain text is easy and maps 1-to-1 with the keyboard you have right in front of you. And even when you start binding commands to keys, there isn't too much choice to be made. Making good complex GUIs is really hard and it seems to have the same kind of inherent complexity like programming - you can't simplify it past giving the developer a really shiny tool with which to put buttons in widgets really easily, which doesn't at all mitigate the hardship of designing exactly where the buttons go, what they say and how they act.
psibi 12y ago
I remember RMS wanting WYSIWYG feature for Emacs recently: http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00515.html http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg005...
jorleif 12y ago
As I see it, WYSIWYG works great if you create a non-interactive thing, like a document, image or video. As soon as you want to present the same information in several formats, or show headlines of articles in several places you need to abstract those things. None of this is impossible with WYSIWYG, but it is usually much more work than just having some kind of plain-text at the core. On the other hand, a well-executed WYSIWYG editor with a well-defined abstract document model would be a great thing. The abstract document model is really essential (and probably plain-text based). The minute you let people WYSIWYG edit, they start doing formatting oriented things such as add spacing using actual spaces. It looks the same on their screen, but might break other formats of the same information. If you tell them to stop doing "that kind of thing", then very soon they are essentially doing plain text-editing with a WYSIWYG tool.
- anon4 12y ago
  > they start doing formatting oriented things such as add spacing using actual spaces Then perhaps the space key on the keyboard should be tied to adding spacing, rather than space characters. That's really a failing of the WYSIWYG editor to take into account normal computer peripherals. The user wants space. The user has a large board with keys on it with a huge "space" key. The user presses the large space key and gets space. A good WYSIWYG editor should account for the fact that my keyboard has keys on it that aren't letters.
  - mantrax5 12y ago
    Let's continue with that approach. Then maybe hitting a letter should only render the letter at the same size and font as the one printed on the keyboard. And if you want to change the font, well it's just a drawing, so you can't. It would make the keyboard non-WYSIWYG.
    - anon4 12y ago
      I was advocating the exact opposite.
robinhoodexe 12y ago
LaTeX was the first that came to my mind when reading it. Very interesting.
workhere-io 12y ago
Once you leave design and layout to non-designers/non-layouters, they will ruin everything, and you will get angry calls from the companies' designers, complaining about how their beautiful design was ruined by someone using Comic Sans on a header. I've seen it happen. This is why CMS makers know that editors / article writers should not be allowed to design/layout pages. Ideally, a WYSIWYG editor in a CMS should only allow users to use bold, italics, links, and perhaps insert small images. Anything more than that, and your web pages end up looking like MySpace/GeoCities.
- TuringTest 12y ago
  There's no reason why designers and ''layouters'' couldn't use WYSIWYG tools nor should be forced to use plain text in order to design the visuals of the site. Your argument is against letting end-users control the whole process, but it's not an argument against WYSIWYG per se.
  - workhere-io 12y ago
    I see what you mean. However, given the large number of different CMSes, I'm not sure designers would appreciate having to re-learn how to design every time they use a new CMS. Right now they use a relatively small "default" set of tools, with PhotoShop being the chief one. I'm not a designer, but my feeling here is that designers wouldn't appreciate the workflow you're suggesting. Any designers here who'd like to weigh in?
    - TuringTest 12y ago
      That's why design tools in visual CMS should be integrated with the current methods that designers use in specialized apps :-) Who says you can't merely reuse the same basic workflows that have been refined by professional designers, augmented with general-purpose mixed visual-textual scripting? That sounds like a winning strategy to me. Designers ''do'' learn ad-hoc batch processing tools for image transformation and publication of the final work; having those standardized would be a net win.
kybernetyk 12y ago
> a programmer-driven choice for Markdown forces the Unix love of editing plain text onto everybody. If you really want revolutionary WYSIWYG interfaces that much then learn programming and develop them yourself. But by then you probably will have recognized the superiority of plain text anyway.
- TuringTest 12y ago
  Plain text is not superior, merely more well-supported because the libraries for it have been around longer, and standards for it had been created. If adequate standards for WYSIWYIG were created, it would be definitely better than plain text from an end-user point of view. In fact, there are numerous cognitive drawbacks that can by corrected by using secondary notation (available either in WYSIWYG and markup), so unadorned plain text is objectively worse than rich text - if only good tools existed for the latter; the author is right in wanting hackers to make those ubiquitous.
  - narag 12y ago
    Plain text is not superior, merely more well-supported... That's a very important fact. If adequate standards for WYSIWYIG were created... I wouldn't say "standard", but more like "paradigm" (nice, first time I've actually used that word). There's that "war on trees" thing that I hope gets abandoned as soon as possible.
erydo 12y ago
This reminds me a lot of Naviedge (http://naviedge.com http://naviedge.com), something I made for hotel concierges a couple years ago. A huge part of the technical burden was making the itinerary editor WYSIWYG in a cross-browser, mobile-friendly way. Much harder than it looks.
bowlofpetunias 12y ago
The author is ignoring the elephant in the room: WYSIWYG is for static, single format output. It doesn't define behavior. Even after so many years, MS Word is still only suited for print and static digital facsimiles of print documents. It fails miserably at anything else it tries to do. Fuck, WYSIWYG is not even suitable for creating good multiple resolution purely static output on nearly identical devices. For the simple reason that if you want to get that right, What You See Is Not What Everybody Else Gets. WYSIWYG only has value in tight, never changing constraints, and those are actually disappearing more and more in favor of interactive, fluid forms of output. WYSIWYG is not the future, it's a relic from the age of print. If there is a way to make the power of raw code more user friendly and accessible, WYSIWYG isn't it. The whole acronym suggest something that doesn't exist and/or is utterly undesirable in a digital world. What you see is not what I want to consume.
- TuringTest 12y ago
  HTML doesn't define behavior either, but it can be combined with tools that do (scripting languages), in the same way that WYSIWYG tools can. That's not a valid argument to prefer textual over visual representation.
ilaksh 12y ago
I believe, contrary to almost all programmers, that this is in fact fundamentally a cultural problem, as the author points, out, and NOT a practical or technical problem. I think the problem is more fundamental than the author suggests though. Fundamentally programming (or software engineering, web development, etc.) is defined by editing textual source code. That's the definition. WYSIWYG is not, by definition, programming. By definition, WYSIWYG is sort of the opposite of programming. Programmers are proud of their ability to create textual source code that is processed to create programs or output. Think about a specific programming activity. For example, creating a web application. If, rather than using code, I use a GUI tool to define the fields in my database, create links between tables, define and style forms for entering and displaying the data, am I programming? If that's the way I build web applications, am I a programmer? What if instead I find a Go-based Object-Relational-Mapper, write some SQL scripts to create the database schema, use SASS to define the styles for my web-based forms, etc. Now, did I do some programming? I created the exact same web application with two completely different approaches. Using the first method, I cannot call myself a programmer (some may argue this, but the general impression most programmers will get, perhaps unfortunately, is that I did not do programming and am not a programmer). In the second method, I used much more effort and achieved the same effect, but I did it by writing textual source code. Therefore in the second case I am a programmer. The difference is simply that I wrote textual source code. Now, I am not saying that WYSIWYG editors cannot produce complex computer programs, even ones that are exactly the same as those created in text editors, or that I believe that WYSIWYG should NOT be considered programming. I think actually we should update our definition of programming to include WYSIWYG, and I believe that old definition is the main thing holding back software engineering. Its really as simple as that. Text = programming. Not text = not programming. That means we are stuck in the 70s forever. Its a cultural failure.
- jorleif 12y ago
  I find this idea of a cultural problem interesting, and in my opinion that we program with plain text is essentially a completely arbitrary choice. That said, in practice almost all of the non-plain-text tools I know are some kind of special case tool and then you still need to write source code for all the pieces of the program that don't fit the mold of the GUI tool.
narag 12y ago
There's no rule as to how good a WYSIWYG interface can be. Make one that's more productive than the corresponding text interface and we'll use it. Hackers aren't holding back anything.
- TuringTest 12y ago
  Are you sure of that? Object orientation was a visual programming environment at first (see Smalltalk), and look at what hackers "from the Unix tradition" have made of it. ;-)
  - narag 12y ago
    Some problems and their evolution is better understood if you focus on what's wrong instead of what's right. Either you have every requirement covered or you're going to fail. There ain't no justice here. You may have created some brilliant architecture, object system, whatever. But if --let's say-- it's too slow, people won't use it.
awjr 12y ago
Not sure his argument stands up very well. Not even MS Word can make something looks good on multiple sizes of paper.
- TuringTest 12y ago
  A single poorly implemented tool doesn't invalidate a whole style of interaction :-)
  - awjr 12y ago
    Accepted, but when your argument uses it as the example to follow it's very hard not to criticise on that basis. I think a more appropriate tool would be Microsoft Visual Studio. Talking about visual tools, many moons ago I worked with NetObjects Fusion (http://netobjects.com/html/website-design-software.html http://netobjects.com/html/website-design-software.html). It actually dumbed down development and did not help you understand the underlying technology. I honestly think in this domain tools that 'hide' implementation from you are not healthy. I do think frameworks have a major role to play, but they 'enable' you to do things better and in a more consistent way.
    - TuringTest 12y ago
      I agree that hiding the underlying technology is not the way to go; though I believe that highly automated "dumbed down" generators like NetObjects may be problematic mainly because of an impedance mistmatch between the interface and the underlying implementation; not because that creation style is essentially wrong. But what if the underlying technology itself were made consistent with that style of development? Things like the Smallest Federated Wiki [1] make content closer to the metal, so that there's just a thin layer between presentation and storage (just like there's one in plain text editors). Also Wikipedia shows how a mostly-visual environment can be the basis for complex categorization and building semi-automatic processes. Most semantic tasks there are handled purely with wiki markup, including the triggering of automatic bot edits against vandalism or for cleanup, or building ; and that markup is susceptible of being made visual (as the new Visual Editor shows, although that's a bit too visual for my tastes). Sure, building new templates and bots on the MediaWiki platform still requires classic development, and there will always be tasks that are better handled with textual descriptions, but there are still huge possibilities to move general development towards a mixed visual/textual environment, keeping the best of each. [1] http://fed.wiki.org/view/welcome-visitors http://fed.wiki.org/view/welcome-visitors
seren 12y ago
The problem with WYSIWYG is that it is hard to automate (and is not composable). I have already worked with a "WYSIWIG tool chain" : you can't build something without someone hitting some button on a graphical interface multiple times at periodical time. It is a real pain when you want to set up a CI server. Or simply if you want to execute a build during your lunch... I have no issue with WYSIWIG per se, but you have to provide me with an alternate path to complete the same task automatically/remotly/with a cron job, etc. So the original poster might have relevant points regarding visual design, but there are reason why developers tend to favor scripts, shell, terminal, it is not purely a cultural issue.
- TuringTest 12y ago
  That's not an inherent property of WYSIWIG. You could equally say that "The problem with building code is that it is hard to automate (and is not composable)", which is true of most programming languages, but then there are IDEs that largely automate tedious programming tasks and there are languages designed for meta-programming; what is lacking is good support from dedicated tools, and a design for automation. I have some ideas of my own on such system could be built, but fortunately many other independent initiatives have emerged lately in that direction (mainly thanks to the ideas by Bret Victor, and all the recent advances in the intersection between Reactive Programming and user interfaces).
  - seren 12y ago
    I wholeheartedly agree it is more an ecosystem issue, but like I said I have no issue with the concept of WYSIWIG itself, just that as of today, they are lacking some characteristics for being efficient. And it is true that the lack of innovation in that area might be a result of habits or culture.
__david__ 12y ago
First off, WYSIWYG HTML editors exist and have existed for years. The author is glossing over the biggest issue. Nobody writes web pages like they use word. Nobody just types up an html page from <html> to </html> and then moves on to the next page—WYSIWYG editors would be great at that. The author mentions "static site generators", and that is the crux of the issue. Nowadays HTML is usually built by templates, sometimes even transpiled from something else entirely (HAML, etc). There's still markup but it's surrounded by template directives which can be fairly complicated turing complete languages in and of themselves (Template::Toolkit and HAML both will let you drop down to the parent language if you need to). Even if there were some sort of nice, usable, visual programming language, WYSIWYG would still be problematic since you would have to show the loops and conditionals and such superimposed with the HTML (otherwise how can you edit something that isn't shown) and as soon as you see the structure of it all, it isn't WYSIWYG any more (by definition). The fact is, we in the hacker culture don't embrace WYSIWYG and hang on to our terminals because we're stubborn old codgers, it's just that we've experienced both and we know which one is better.
- jules 12y ago
  I think the author is rather talking about <textarea> vs rich text editor widgets for user supplied content, and not really about things like Dreamweaver.
  - Joeboy 12y ago
    Ten years ago I worked for a web dev company that embraced rich text editor widgets for user supplied content. It was great. We charged them an arm and a leg for the ability to edit their content, then we charged them more to fix it when they broke it or couldn't do what they wanted, which was always. Subsequently, when I'm doing websites for myself or for people who I like, I don't use rich text editor widgets. It's possible I'm stuck in the past, but it's not an ideological issue.
    - jules 12y ago
      I have the opposite experience. Clients love WYSIWYG for two reasons: 1. They don't need to train their data entry employees in markdown or similar. 2. They can copy paste rich text from MS Word, rather than having to pay somebody to transliterate it into markdown. The number of support requests for WYSIWYG is vastly lower than for markdown.
Dn_Ab 12y ago
I picked up an allergy for WYSIWYG while reading through the works of Engelbart. It's not flexible enough and locks you down to a way of think which does not properly leverage the advantages of our new medium; related: >Our approach was very different from what they called "office automation," which was about automating the paperwork of secretaries. That became the focus of Xerox PARC in the '70s. They were quite amazed that they could actually get text on the screen to appear the way it would when printed by a laser printer. Sure, that was an enormous accomplishment, and understandably it swayed their thinking. They called it "what you see is what you get" editing, or WYSIWYG. I say, yeah, but that's all you get. Once people have experienced the more flexible manipulation of text that NLS allows, they find the paper model restrictive. We weren't interested in "automation" but in "augmentation." We were not just building a tool, we were designing an entire system for working with knowledge - Douglas Engelbart; http://archive.wired.com/wired/archive/12.01/mouse_pr.html http://archive.wired.com/wired/archive/12.01/mouse_pr.html > Question: Isn't it great the we now have WYSIWYG technology so what you see is what yo get. You can print it out, you have wonderful, good looking documents with all kinds of typefaces? Answer: That really is nice for the people who want to stay where they like used to be... That ignoring hugely all the other options you have... http://www.invisiblerevolution.net/engelbart/glossary/wysiwyg.html http://www.invisiblerevolution.net/engelbart/glossary/wysiwy...
- easytiger 12y ago
  Here is the way I look at it. If one is capable of holding the entire conceptual abstract ephemera relating to the concrete problem you are solving, then WYSIWYG is mentally jarring as it often takes away from proper semantic representations of concepts. Indeed very often WYSIWYG attempts to hide semantic meaning from users in an attempt to make it seem easier. Of course for the simpler case this is true. But for complex cases where structure and uniformity and restructuring are important use cases then WYSIWYG is destructive compared with a much simpler markup. I'd also argue with little evidence that there is something mentally jarring for the competent about self expression when having to await moving your arm to do something with a mouse in the midst of the flow of editing.
MarcScott 12y ago
The main reason I prefer to work in a text editor, is it limits the number of tools I have to learn to use. When I used to work as a 3D designer, I became an expert at Cinema 4D. But there were times I had to switch to another application due to the limits of C4D, and I would become lost in the UI of Maya or Max, unable to perform the simplest of actions without the assistance of Google. My preferred text editor is Emacs, and I rarely need to use another application other than Firefox. With my text editor I can code, write markup, keep a calendar and todo list, open a shell, chat on IRC. In a WYSIWYG world, you have a dozen different applications to perform a dozen different tasks, and each requiring an in depth knowledge of that application. Yet in reality, each application is simply editing plain text.
- Angostura 12y ago
  Your argument seems to be that switching between WYSIWYG applications can be confusing whereas not switching between text based tools is not. Presumably if you were continually switching between multiple text-based editors, each with their own abstruse command key combinations, you would find that even more difficult than switching between graphical tools.
  - MarcScott 12y ago
    Switching between WYSIWYG applications is confusing and it would be if I was switching between multiple text editors as well. It would be a nightmare if I had to use Vim to code, Emacs for my calendar and Sublime for markdown. I don't have to though, as I can do pretty much everything I want from a single text editor. Yes, there are different 'modes' to master, but most of the underlying commands are shared between modes so the learning curve is shallower.
chipsy 12y ago
One of the goals the VPRI team had in the STEPS project was to put together a WYSIWYG document editor. They did so within their 20,000 total lines of code limit. Which isn't to say that doing it is easy just because the amount of code needed is small - it's more a statement about the industrialized model of coding that we've chained ourselves to. Nobody can afford the pure-research grade of time and dedication to build and iterate towards a beautiful design that is not just engineered well, but aspires to a mathematical grade of implementation with not a character wasted. So we build ungainly things to meet our hair-on-fire needs, and copy things out of them when happenstance allows them to be reused. And so in all likelihood we're constantly, invisibly shortchanging the future because we have to focus on shipping our shovelware instead. And I think the text files end up being part of that, because they're precisely the protocol that makes it so easy for stuff to be copied _inelegantly_. We bend everything around whether it's easy to copy from text and whether the editor we already use can read it.
flohofwoe 12y ago
Doing a WYSIWYG tool which doesn't get in the way of advanced users is extremely hard. Look at 3D content creation tools like Maya, this has been built from the ground up to be programmable and extensible over nearly 20 years, while still being an intuitve "WYSIWYG" tool. Someone completely new to 3D modelling and animation would still be completely lost, but that's not the target audience (that's where I lost the author, does he want to empower 'noobs' by giving them the illusion that they can accomplish great things without learning, or does he really care about productivity for power users). In my experience, good tools can have complex (UI) interfaces as long as the interface is discoverable, and they should be automatabable/customizable through programming interfaces. I see myself drifting back to the command line in the recent years, just because many things don't require the overhead of an UI.
JanneVee 12y ago
It is not fear, when I design for me I don't do a WYSIWYG unless it has some benefit or trade off for me. Now that benefit can be monetary i.e. I get paid to do WYSIWYG. I'm a selfish git I know... but that is the way it is. I'm not afraid of it, I'm just being me.
Htsthbjig 12y ago
I strongly disagree. The author is ignorant of the issue, but instead of realizing what he does not know about, he creates an entire narrative with the elements he has. The problem about web interfaces is not programmers, it is that: You have absolutely NO CONTROL on the ending display. That's it. You have not control on aspect ratio, on resolution, on how fast the computer is and even in the link velocity. So if you are a designer and something WYSIWYG works so well in your retina display screen and fiber optic Internet connection does not mean that works out there on a myriad of different user choices. WSYIWYG is a terrible solution when you have different alternatives. E.g If you have 6 displays aspect ratios(4/3 16/9 the new surface pro 3/2 and the portrait version of those), 4 main resolutions, 3 main Internet velocities, and 4 computer power(based on how old the computer is), you have: 6x4x3x4 = 288 possibilities. Now, have fun testing at least 288 different versions of everything you do (there are other possibilities like people with disabilities that in some jobs like gobertment work you have to do), while the Unix Hackers, and children eaters Gatekeepers just do it once. I for one want to improve the system, but text(code) is one of the best solutions we have so far. The reason there is no something better is because people are able to spend a significant amount of time ranting about others instead of doing something about it(and facing lots of problems that ranting does not have like the possibility of failure as we underestimated those while on our arm chair).
hbogert 12y ago
"What you see is what you get". Great! - however it assumes that your audience is using the same media presenter, e.g. use Word to depict an A4 and you print an A4. What if I want it as a webpage as well, do I have to type it twice now? Does someone remember how horrible this even is when you export a webpage from Word. This stuff is not solved, and is only getting more difficult in the age of 3" up to 70" screens
poissonpie 12y ago
I think wysiwyg editors are also only useful in certain cases - CMSs, blogs, DTPs - the sort of systems where the data entered is the information you will see. There are large categories of applications, however, where the data entered is first aggregated/manipulated before it is useful for any sort of output - in these cases, wysiwyg is just not the way forward.

51 points by jeswin 12y ago

Uhmm. Ok, let's say you're Tour de France competitor, and you're told to use this: http://www.christydena.com/blog/wp-content/uploads/2010/02/trainingwheels.jpg http://www.christydena.com/blog/wp-content/uploads/2010/02/t... Is "fear" the correct word for your reaction? WYSIWYG is a good thing in predominantly visual programs (photo editing, vector illustrations, animation tools). WYSIWYG becomes a problem when the content being entered has semantics without explicit visual cues. By definition you can't have a "WYSIWYG" for semantical information, and if you give people a WYSIWYG HTML editor to enter content, they'll just tweak the code until it "looks" right, which will bomb when said content has to be transferred to a new medium (say, non-HTML). People may be liking Word, but the majority don't use it semantically, they just mash the font settings until the document looks approximately correct, never mind the document outline is a mess, because half their headlines are not headlines, but paragraphs with enlarged text.

simias 12y ago
You're right, I think the author has a point but putting it all under the umbrella of "WYSIWYG" is not helping it. For instance, I agree that the current mostly text-based interface to programming could be improved dramatically by abstracting ourselves away from the source files towards a more visual representation of the code, showing dependencies between functions etc... Syntax highlighting doesn't quite cut it. I wouldn't call that "WYSIWYG" at all though. In essence most source code is a graph of function calls and it's very hard to represent that in plain text. There have been some efforts in that direction (lately I remember the light table editor for instance) but at the end of the day I'm still editing ASCII files in emacs... What we need isn't WYSIWYG, it's better visual representation of the data we're manipulating.
- markrages 12y ago
  I notice your response was in the form of a few paragraphs of text, rather than a photo or diagram. Most conversation are "text-based". Our human brains have hardware acceleration for text processing and we're quite good at it. Since programming environments exist to make the best impedance match between programmer and machine, they use text. Language uses incredible composability to encode great complexity. Flowcharts are one implementation of what you propose. Or LabView: http://www.ni.com/cms/images/devzone/pub/nrjsxmfm912163998723206173.jpg http://www.ni.com/cms/images/devzone/pub/nrjsxmfm91216399872...
  - TuringTest 12y ago
    Our human brains have hardware acceleration for image processing as well. Limiting ourselves to text is wasting half our natural resources. Flowcharts and LabView are old paradigms, they have and are problematic for abstract tasks (they're only good for data manipulation). What's needed is a new style of programming that combined the best of visual and textual representations. Wolfram Language [1] and Bret Victor's Inventing on Principle [2] are more modern approaches in that direction. [1] http://www.wolfram.com/language/ http://www.wolfram.com/language/ [2] http://vimeo.com/36579366 http://vimeo.com/36579366
  - simias 12y ago
    You'll also notice that while the comments are all plaintext, they're presented hierarchically as nested trees. There's also a hyperlink in your comment that I can follow easily, that's not plaintext. I'm not saying plaintext is bad, I'm just saying that we're not stuck with 80x25 green-on-black terminals anymore, there's room for improvement using our modern display capabilities.
    - mantrax5 12y ago
      Why yes, we're not stuck with 80x25 green on black terminals. Why even mention it? By the way that nested hierarchical tree is also written in text (HTML and CSS). So is the hyperlink. URLs? Text. Check any modern IDE and you'll see similar visualizations over text based source code. I can explore my project in a tree-based outline in my IDE. I can open my classes as an UML diagram. Turns out we're already in the future. Celebrate?
- TuringTest 12y ago
  I think you've identified an interesting problem in the "cultural dialog" around this subject - that legacy terms like "WYSIWYG" and "Visual Programming" are holding back conversation. The core idea in the article (that "Hacker Culture’s bias is holding back interface design") is a solid one, but a new term would make it easier to identify the problem without all the implications carried out by the broken tools of old. Maybe some new term like "Rich Visual Interaction", or "Web Application IDEs", or anything that ties the idea of development with using modern visual technologies and representations would help.
kijin 12y ago
> By definition you can't have a "WYSIWYG" for semantical information, and if you give people a WYSIWYG HTML editor to enter content, they'll just tweak the code until it "looks" right, which will bomb when said content has to be transferred to a new medium (say, non-HTML). That problem can be mostly fixed with clever programming. Does the content seem to include a bunch of one-line paragraphs, all of which share roughly the same font that is different from the rest of the content? Treat them as headlines. Have a bit of tolerance for people who can't distinguish 13pt from 14pt, but if the sizes or other styling differ considerably, try to decide which ones are <h1> and which ones are <h2>, etc. Does the content include a bunch of consecutive paragraphs that begin with numerals (1. 2. 3.) or hyphens/asterisks? Turn them into <ol> and <ul> respectively. C'mon, even Microsoft Word knows how to do this, and the user can override it if the program guesses wrong. There's no reason why an open-source HTML editor can't do the same or better. You could even have the best of both worlds: the editor might recognize Markdown syntax and automatically convert them to the corresponding HTML markup for live preview. For example, if you begin and end a word with an underscore, put an <em> around it. (You can already configure Microsoft Word to do this.) If you begin a paragraph with ###, >, or four spaces, turn it into <h3>, <blockquote>, and <pre><code> respectively. Okay, but what if a piece of user-submitted content is so messed up that it is impossible to get any semantical information out of it? Well, think about it this way: whoever produced that content probably didn't intend to convey any semantical information anyway. By failing to determine the semantic structure of that content, the computer is actually guessing the author's intention correctly. Just slap a CSS normalizer on that piece of cow dung, and it will look more or less the same in all current and future browsers (which is probably what the author intended). The only thing that matters is that you don't produce such content. If someone else wants to shoot themselves in the balls with Comic Sans, why stop them? It's what they want. The primary reason why WYSIWYG editors carry a stigma is that the first generation of popular editors, such as TinyMCE and FCKEditor (the precursor to CKEditor), tended to produce horribly broken markup. But that was 10 years ago, and now we have much better editors. And we can make them even better if we want to.

asgard1024 12y ago

I think hackers (in any field) like "productive" user interfaces, everything else is irrelevant. There are productive WYSIWYGs and GUIs, look at e.g. Blender, but they are usually hard to learn and/or they look really ugly, so they are not appreciated by commoners or designers. For the UI to be productive, it has to have a couple of features: - Highly configurable, possibility of presets - Accessible only by keyboard - Available for scripting You can combine those with smooth learning curve and nice design, but it's very hard thing to do. That's why application builders (on either side) usually don't bother.

anon4 12y ago
> very hard thing to do That's pretty much the entire reason. Plain text is easy and maps 1-to-1 with the keyboard you have right in front of you. And even when you start binding commands to keys, there isn't too much choice to be made. Making good complex GUIs is really hard and it seems to have the same kind of inherent complexity like programming - you can't simplify it past giving the developer a really shiny tool with which to put buttons in widgets really easily, which doesn't at all mitigate the hardship of designing exactly where the buttons go, what they say and how they act.

psibi 12y ago

I remember RMS wanting WYSIWYG feature for Emacs recently: http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00515.html http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg005...

jorleif 12y ago

As I see it, WYSIWYG works great if you create a non-interactive thing, like a document, image or video. As soon as you want to present the same information in several formats, or show headlines of articles in several places you need to abstract those things. None of this is impossible with WYSIWYG, but it is usually much more work than just having some kind of plain-text at the core. On the other hand, a well-executed WYSIWYG editor with a well-defined abstract document model would be a great thing. The abstract document model is really essential (and probably plain-text based). The minute you let people WYSIWYG edit, they start doing formatting oriented things such as add spacing using actual spaces. It looks the same on their screen, but might break other formats of the same information. If you tell them to stop doing "that kind of thing", then very soon they are essentially doing plain text-editing with a WYSIWYG tool.

anon4 12y ago
> they start doing formatting oriented things such as add spacing using actual spaces Then perhaps the space key on the keyboard should be tied to adding spacing, rather than space characters. That's really a failing of the WYSIWYG editor to take into account normal computer peripherals. The user wants space. The user has a large board with keys on it with a huge "space" key. The user presses the large space key and gets space. A good WYSIWYG editor should account for the fact that my keyboard has keys on it that aren't letters.
- mantrax5 12y ago
  Let's continue with that approach. Then maybe hitting a letter should only render the letter at the same size and font as the one printed on the keyboard. And if you want to change the font, well it's just a drawing, so you can't. It would make the keyboard non-WYSIWYG.
  - anon4 12y ago
    I was advocating the exact opposite.

robinhoodexe 12y ago

LaTeX was the first that came to my mind when reading it. Very interesting.

workhere-io 12y ago

Once you leave design and layout to non-designers/non-layouters, they will ruin everything, and you will get angry calls from the companies' designers, complaining about how their beautiful design was ruined by someone using Comic Sans on a header. I've seen it happen. This is why CMS makers know that editors / article writers should not be allowed to design/layout pages. Ideally, a WYSIWYG editor in a CMS should only allow users to use bold, italics, links, and perhaps insert small images. Anything more than that, and your web pages end up looking like MySpace/GeoCities.

TuringTest 12y ago
There's no reason why designers and ''layouters'' couldn't use WYSIWYG tools nor should be forced to use plain text in order to design the visuals of the site. Your argument is against letting end-users control the whole process, but it's not an argument against WYSIWYG per se.
- workhere-io 12y ago
  I see what you mean. However, given the large number of different CMSes, I'm not sure designers would appreciate having to re-learn how to design every time they use a new CMS. Right now they use a relatively small "default" set of tools, with PhotoShop being the chief one. I'm not a designer, but my feeling here is that designers wouldn't appreciate the workflow you're suggesting. Any designers here who'd like to weigh in?
  - TuringTest 12y ago
    That's why design tools in visual CMS should be integrated with the current methods that designers use in specialized apps :-) Who says you can't merely reuse the same basic workflows that have been refined by professional designers, augmented with general-purpose mixed visual-textual scripting? That sounds like a winning strategy to me. Designers ''do'' learn ad-hoc batch processing tools for image transformation and publication of the final work; having those standardized would be a net win.

kybernetyk 12y ago

> a programmer-driven choice for Markdown forces the Unix love of editing plain text onto everybody. If you really want revolutionary WYSIWYG interfaces that much then learn programming and develop them yourself. But by then you probably will have recognized the superiority of plain text anyway.

TuringTest 12y ago
Plain text is not superior, merely more well-supported because the libraries for it have been around longer, and standards for it had been created. If adequate standards for WYSIWYIG were created, it would be definitely better than plain text from an end-user point of view. In fact, there are numerous cognitive drawbacks that can by corrected by using secondary notation (available either in WYSIWYG and markup), so unadorned plain text is objectively worse than rich text - if only good tools existed for the latter; the author is right in wanting hackers to make those ubiquitous.
- narag 12y ago
  Plain text is not superior, merely more well-supported... That's a very important fact. If adequate standards for WYSIWYIG were created... I wouldn't say "standard", but more like "paradigm" (nice, first time I've actually used that word). There's that "war on trees" thing that I hope gets abandoned as soon as possible.

erydo 12y ago

This reminds me a lot of Naviedge (http://naviedge.com http://naviedge.com), something I made for hotel concierges a couple years ago. A huge part of the technical burden was making the itinerary editor WYSIWYG in a cross-browser, mobile-friendly way. Much harder than it looks.

bowlofpetunias 12y ago

The author is ignoring the elephant in the room: WYSIWYG is for static, single format output. It doesn't define behavior. Even after so many years, MS Word is still only suited for print and static digital facsimiles of print documents. It fails miserably at anything else it tries to do. Fuck, WYSIWYG is not even suitable for creating good multiple resolution purely static output on nearly identical devices. For the simple reason that if you want to get that right, What You See Is Not What Everybody Else Gets. WYSIWYG only has value in tight, never changing constraints, and those are actually disappearing more and more in favor of interactive, fluid forms of output. WYSIWYG is not the future, it's a relic from the age of print. If there is a way to make the power of raw code more user friendly and accessible, WYSIWYG isn't it. The whole acronym suggest something that doesn't exist and/or is utterly undesirable in a digital world. What you see is not what I want to consume.

TuringTest 12y ago
HTML doesn't define behavior either, but it can be combined with tools that do (scripting languages), in the same way that WYSIWYG tools can. That's not a valid argument to prefer textual over visual representation.

ilaksh 12y ago

I believe, contrary to almost all programmers, that this is in fact fundamentally a cultural problem, as the author points, out, and NOT a practical or technical problem. I think the problem is more fundamental than the author suggests though. Fundamentally programming (or software engineering, web development, etc.) is defined by editing textual source code. That's the definition. WYSIWYG is not, by definition, programming. By definition, WYSIWYG is sort of the opposite of programming. Programmers are proud of their ability to create textual source code that is processed to create programs or output. Think about a specific programming activity. For example, creating a web application. If, rather than using code, I use a GUI tool to define the fields in my database, create links between tables, define and style forms for entering and displaying the data, am I programming? If that's the way I build web applications, am I a programmer? What if instead I find a Go-based Object-Relational-Mapper, write some SQL scripts to create the database schema, use SASS to define the styles for my web-based forms, etc. Now, did I do some programming? I created the exact same web application with two completely different approaches. Using the first method, I cannot call myself a programmer (some may argue this, but the general impression most programmers will get, perhaps unfortunately, is that I did not do programming and am not a programmer). In the second method, I used much more effort and achieved the same effect, but I did it by writing textual source code. Therefore in the second case I am a programmer. The difference is simply that I wrote textual source code. Now, I am not saying that WYSIWYG editors cannot produce complex computer programs, even ones that are exactly the same as those created in text editors, or that I believe that WYSIWYG should NOT be considered programming. I think actually we should update our definition of programming to include WYSIWYG, and I believe that old definition is the main thing holding back software engineering. Its really as simple as that. Text = programming. Not text = not programming. That means we are stuck in the 70s forever. Its a cultural failure.

jorleif 12y ago
I find this idea of a cultural problem interesting, and in my opinion that we program with plain text is essentially a completely arbitrary choice. That said, in practice almost all of the non-plain-text tools I know are some kind of special case tool and then you still need to write source code for all the pieces of the program that don't fit the mold of the GUI tool.

narag 12y ago

There's no rule as to how good a WYSIWYG interface can be. Make one that's more productive than the corresponding text interface and we'll use it. Hackers aren't holding back anything.

TuringTest 12y ago
Are you sure of that? Object orientation was a visual programming environment at first (see Smalltalk), and look at what hackers "from the Unix tradition" have made of it. ;-)
- narag 12y ago
  Some problems and their evolution is better understood if you focus on what's wrong instead of what's right. Either you have every requirement covered or you're going to fail. There ain't no justice here. You may have created some brilliant architecture, object system, whatever. But if --let's say-- it's too slow, people won't use it.

awjr 12y ago

Not sure his argument stands up very well. Not even MS Word can make something looks good on multiple sizes of paper.

TuringTest 12y ago
A single poorly implemented tool doesn't invalidate a whole style of interaction :-)
- awjr 12y ago
  Accepted, but when your argument uses it as the example to follow it's very hard not to criticise on that basis. I think a more appropriate tool would be Microsoft Visual Studio. Talking about visual tools, many moons ago I worked with NetObjects Fusion (http://netobjects.com/html/website-design-software.html http://netobjects.com/html/website-design-software.html). It actually dumbed down development and did not help you understand the underlying technology. I honestly think in this domain tools that 'hide' implementation from you are not healthy. I do think frameworks have a major role to play, but they 'enable' you to do things better and in a more consistent way.
  - TuringTest 12y ago
    I agree that hiding the underlying technology is not the way to go; though I believe that highly automated "dumbed down" generators like NetObjects may be problematic mainly because of an impedance mistmatch between the interface and the underlying implementation; not because that creation style is essentially wrong. But what if the underlying technology itself were made consistent with that style of development? Things like the Smallest Federated Wiki [1] make content closer to the metal, so that there's just a thin layer between presentation and storage (just like there's one in plain text editors). Also Wikipedia shows how a mostly-visual environment can be the basis for complex categorization and building semi-automatic processes. Most semantic tasks there are handled purely with wiki markup, including the triggering of automatic bot edits against vandalism or for cleanup, or building ; and that markup is susceptible of being made visual (as the new Visual Editor shows, although that's a bit too visual for my tastes). Sure, building new templates and bots on the MediaWiki platform still requires classic development, and there will always be tasks that are better handled with textual descriptions, but there are still huge possibilities to move general development towards a mixed visual/textual environment, keeping the best of each. [1] http://fed.wiki.org/view/welcome-visitors http://fed.wiki.org/view/welcome-visitors

seren 12y ago

The problem with WYSIWYG is that it is hard to automate (and is not composable). I have already worked with a "WYSIWIG tool chain" : you can't build something without someone hitting some button on a graphical interface multiple times at periodical time. It is a real pain when you want to set up a CI server. Or simply if you want to execute a build during your lunch... I have no issue with WYSIWIG per se, but you have to provide me with an alternate path to complete the same task automatically/remotly/with a cron job, etc. So the original poster might have relevant points regarding visual design, but there are reason why developers tend to favor scripts, shell, terminal, it is not purely a cultural issue.

TuringTest 12y ago
That's not an inherent property of WYSIWIG. You could equally say that "The problem with building code is that it is hard to automate (and is not composable)", which is true of most programming languages, but then there are IDEs that largely automate tedious programming tasks and there are languages designed for meta-programming; what is lacking is good support from dedicated tools, and a design for automation. I have some ideas of my own on such system could be built, but fortunately many other independent initiatives have emerged lately in that direction (mainly thanks to the ideas by Bret Victor, and all the recent advances in the intersection between Reactive Programming and user interfaces).
- seren 12y ago
  I wholeheartedly agree it is more an ecosystem issue, but like I said I have no issue with the concept of WYSIWIG itself, just that as of today, they are lacking some characteristics for being efficient. And it is true that the lack of innovation in that area might be a result of habits or culture.

__david__ 12y ago

First off, WYSIWYG HTML editors exist and have existed for years. The author is glossing over the biggest issue. Nobody writes web pages like they use word. Nobody just types up an html page from <html> to </html> and then moves on to the next page—WYSIWYG editors would be great at that. The author mentions "static site generators", and that is the crux of the issue. Nowadays HTML is usually built by templates, sometimes even transpiled from something else entirely (HAML, etc). There's still markup but it's surrounded by template directives which can be fairly complicated turing complete languages in and of themselves (Template::Toolkit and HAML both will let you drop down to the parent language if you need to). Even if there were some sort of nice, usable, visual programming language, WYSIWYG would still be problematic since you would have to show the loops and conditionals and such superimposed with the HTML (otherwise how can you edit something that isn't shown) and as soon as you see the structure of it all, it isn't WYSIWYG any more (by definition). The fact is, we in the hacker culture don't embrace WYSIWYG and hang on to our terminals because we're stubborn old codgers, it's just that we've experienced both and we know which one is better.

jules 12y ago
I think the author is rather talking about <textarea> vs rich text editor widgets for user supplied content, and not really about things like Dreamweaver.
- Joeboy 12y ago
  Ten years ago I worked for a web dev company that embraced rich text editor widgets for user supplied content. It was great. We charged them an arm and a leg for the ability to edit their content, then we charged them more to fix it when they broke it or couldn't do what they wanted, which was always. Subsequently, when I'm doing websites for myself or for people who I like, I don't use rich text editor widgets. It's possible I'm stuck in the past, but it's not an ideological issue.
  - jules 12y ago
    I have the opposite experience. Clients love WYSIWYG for two reasons: 1. They don't need to train their data entry employees in markdown or similar. 2. They can copy paste rich text from MS Word, rather than having to pay somebody to transliterate it into markdown. The number of support requests for WYSIWYG is vastly lower than for markdown.

Dn_Ab 12y ago

I picked up an allergy for WYSIWYG while reading through the works of Engelbart. It's not flexible enough and locks you down to a way of think which does not properly leverage the advantages of our new medium; related: >Our approach was very different from what they called "office automation," which was about automating the paperwork of secretaries. That became the focus of Xerox PARC in the '70s. They were quite amazed that they could actually get text on the screen to appear the way it would when printed by a laser printer. Sure, that was an enormous accomplishment, and understandably it swayed their thinking. They called it "what you see is what you get" editing, or WYSIWYG. I say, yeah, but that's all you get. Once people have experienced the more flexible manipulation of text that NLS allows, they find the paper model restrictive. We weren't interested in "automation" but in "augmentation." We were not just building a tool, we were designing an entire system for working with knowledge - Douglas Engelbart; http://archive.wired.com/wired/archive/12.01/mouse_pr.html http://archive.wired.com/wired/archive/12.01/mouse_pr.html > Question: Isn't it great the we now have WYSIWYG technology so what you see is what yo get. You can print it out, you have wonderful, good looking documents with all kinds of typefaces? Answer: That really is nice for the people who want to stay where they like used to be... That ignoring hugely all the other options you have... http://www.invisiblerevolution.net/engelbart/glossary/wysiwyg.html http://www.invisiblerevolution.net/engelbart/glossary/wysiwy...

easytiger 12y ago
Here is the way I look at it. If one is capable of holding the entire conceptual abstract ephemera relating to the concrete problem you are solving, then WYSIWYG is mentally jarring as it often takes away from proper semantic representations of concepts. Indeed very often WYSIWYG attempts to hide semantic meaning from users in an attempt to make it seem easier. Of course for the simpler case this is true. But for complex cases where structure and uniformity and restructuring are important use cases then WYSIWYG is destructive compared with a much simpler markup. I'd also argue with little evidence that there is something mentally jarring for the competent about self expression when having to await moving your arm to do something with a mouse in the midst of the flow of editing.

MarcScott 12y ago

The main reason I prefer to work in a text editor, is it limits the number of tools I have to learn to use. When I used to work as a 3D designer, I became an expert at Cinema 4D. But there were times I had to switch to another application due to the limits of C4D, and I would become lost in the UI of Maya or Max, unable to perform the simplest of actions without the assistance of Google. My preferred text editor is Emacs, and I rarely need to use another application other than Firefox. With my text editor I can code, write markup, keep a calendar and todo list, open a shell, chat on IRC. In a WYSIWYG world, you have a dozen different applications to perform a dozen different tasks, and each requiring an in depth knowledge of that application. Yet in reality, each application is simply editing plain text.

Angostura 12y ago
Your argument seems to be that switching between WYSIWYG applications can be confusing whereas not switching between text based tools is not. Presumably if you were continually switching between multiple text-based editors, each with their own abstruse command key combinations, you would find that even more difficult than switching between graphical tools.
- MarcScott 12y ago
  Switching between WYSIWYG applications is confusing and it would be if I was switching between multiple text editors as well. It would be a nightmare if I had to use Vim to code, Emacs for my calendar and Sublime for markdown. I don't have to though, as I can do pretty much everything I want from a single text editor. Yes, there are different 'modes' to master, but most of the underlying commands are shared between modes so the learning curve is shallower.

chipsy 12y ago

One of the goals the VPRI team had in the STEPS project was to put together a WYSIWYG document editor. They did so within their 20,000 total lines of code limit. Which isn't to say that doing it is easy just because the amount of code needed is small - it's more a statement about the industrialized model of coding that we've chained ourselves to. Nobody can afford the pure-research grade of time and dedication to build and iterate towards a beautiful design that is not just engineered well, but aspires to a mathematical grade of implementation with not a character wasted. So we build ungainly things to meet our hair-on-fire needs, and copy things out of them when happenstance allows them to be reused. And so in all likelihood we're constantly, invisibly shortchanging the future because we have to focus on shipping our shovelware instead. And I think the text files end up being part of that, because they're precisely the protocol that makes it so easy for stuff to be copied _inelegantly_. We bend everything around whether it's easy to copy from text and whether the editor we already use can read it.

flohofwoe 12y ago

Doing a WYSIWYG tool which doesn't get in the way of advanced users is extremely hard. Look at 3D content creation tools like Maya, this has been built from the ground up to be programmable and extensible over nearly 20 years, while still being an intuitve "WYSIWYG" tool. Someone completely new to 3D modelling and animation would still be completely lost, but that's not the target audience (that's where I lost the author, does he want to empower 'noobs' by giving them the illusion that they can accomplish great things without learning, or does he really care about productivity for power users). In my experience, good tools can have complex (UI) interfaces as long as the interface is discoverable, and they should be automatabable/customizable through programming interfaces. I see myself drifting back to the command line in the recent years, just because many things don't require the overhead of an UI.

JanneVee 12y ago

It is not fear, when I design for me I don't do a WYSIWYG unless it has some benefit or trade off for me. Now that benefit can be monetary i.e. I get paid to do WYSIWYG. I'm a selfish git I know... but that is the way it is. I'm not afraid of it, I'm just being me.

Htsthbjig 12y ago

I strongly disagree. The author is ignorant of the issue, but instead of realizing what he does not know about, he creates an entire narrative with the elements he has. The problem about web interfaces is not programmers, it is that: You have absolutely NO CONTROL on the ending display. That's it. You have not control on aspect ratio, on resolution, on how fast the computer is and even in the link velocity. So if you are a designer and something WYSIWYG works so well in your retina display screen and fiber optic Internet connection does not mean that works out there on a myriad of different user choices. WSYIWYG is a terrible solution when you have different alternatives. E.g If you have 6 displays aspect ratios(4/3 16/9 the new surface pro 3/2 and the portrait version of those), 4 main resolutions, 3 main Internet velocities, and 4 computer power(based on how old the computer is), you have: 6x4x3x4 = 288 possibilities. Now, have fun testing at least 288 different versions of everything you do (there are other possibilities like people with disabilities that in some jobs like gobertment work you have to do), while the Unix Hackers, and children eaters Gatekeepers just do it once. I for one want to improve the system, but text(code) is one of the best solutions we have so far. The reason there is no something better is because people are able to spend a significant amount of time ranting about others instead of doing something about it(and facing lots of problems that ranting does not have like the possibility of failure as we underestimated those while on our arm chair).

hbogert 12y ago

"What you see is what you get". Great! - however it assumes that your audience is using the same media presenter, e.g. use Word to depict an A4 and you print an A4. What if I want it as a webpage as well, do I have to type it twice now? Does someone remember how horrible this even is when you export a webpage from Word. This stuff is not solved, and is only getting more difficult in the age of 3" up to 70" screens

poissonpie 12y ago

I think wysiwyg editors are also only useful in certain cases - CMSs, blogs, DTPs - the sort of systems where the data entered is the information you will see. There are large categories of applications, however, where the data entered is first aggregated/manipulated before it is useful for any sort of output - in these cases, wysiwyg is just not the way forward.