Making Websites With Actions, Not Words
There’s a post on Geek & Mild about Adobe’s new web development tool called Muse. While I’ll be the first to say that building a quality website requires knowing the code behind it, I’m not nearly as quick to say that there is no place for a good WYSIWYG tool for web publishing.
Once upon a time, before the Macintosh came along and before I was born, desktop publishing was done with code1. The first Mac changed that very quickly with a WYSIWYG editing tool. Then the Web came along and WYSIWYG editors popped almost immediately… but never gained traction.
Why did it work so well in print and so poorly in web? The obvious answer is interactivity. You can’t respond to user interactions with simple shapes and text blocks. However, I think there is room for an application that would actually work in the real world.
Let’s start with the assumption that aside from basic animations, you’ll need to resort to code to implement a truly dynamic site using server & client-side programming. What’s left, though, is enough for a lot of businesses and people: static sites.
Designing a static site really is something that can be visualized. For example, when you place a <div>, you’re placing a block that spans the entire width of the page and one text-line of height. To position it on the page, setting float to left or right shoves it to the left or right of the parent element. The CSS properties to further customize these elements are, I think, can be easily understood by the average user.
Furthermore, let’s simplify making a site look good by limiting this idea to making CSS3 sites. This allows for lots of block-level effects that will add style to the page without requiring background images and all that nonsense. That’ll come in real handy for menus.
Speaking of which, menus, popovers and carousels are going to need Javascript to work, but these are also common things - I think a program could generate these. Say you want a carousel - drag in a special <div> object that contains a pre-made carousel with GUI controls for flipping through the pages of it, then link them to links on the design by drawing a line from a link to the GUI representation of the tab with the mouse/finger.
Furthermore, anywhere you can add text, you can also add tags that a very simple CMS (PHP with flat-file databases, that runs on pretty much any web-host without requiring configuration) can interpret.
Really, I think any simple HTML element can be easily manipulated with a WYSIWYG interface. It’s just a matter of translating it to a UI paradigm that actually makes sense to people used to dragging and dropping text, shapes and images, with very easy-to-understand and reliable configuration options.
I really believe that making a good WYSIWYG website editor is possible. I really think every HTML structural element can be well-represented visually (the display: inline elements would need non-breaking spaces in them by default, though), and adding styles should simply be a matter of setting style options until the user finds one they like. Even simple Javascript-powered menus and carousels should be doable with a well-designed UI. WYSIWYG web development should be much more of a UI/UX challenge than a development one - if the development gets tricky, then you’re being too ambitious and you’re wrecking the application.
Is Muse that application? I read “AIR-powered” and immediately assumed the UI would be terrible, so I don’t and won’t know because I don’t ever intend to touch it. However, it’s entirely possible a good basic WYSIWYG web-design application can be written. Indeed, many probably already have - I’m not in that market because I know I can do more with code. That doesn’t make WYSIWYG editors worthless, though, and I think great things could be done with them if the app is carefully crafted.
-
This was done using TeX and LaTeX if Wikipedia is to be believed, though my college professors had told me it was PostScript. God, that’s a ghastly thought, marking up pages in PS. ↩