7 ms·
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.j
by 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 agoYou'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 agoI 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 agoOur 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 agoYou'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 agoWhy 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 agoI 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.