Fellows,
This is home work. I'm analising the Poetry section of the Monastery under various usability concepts exposed by the Web Applications Design teacher at my graduation course and needed to listen what you think about using a subset of HTML as our publishing language: is this a feature? Is this a Bad Thing TM? And, most important of your own opinion about this being a feature or a bug, why do you see using a subset of HTML for publishing this way?
My own view is: this is a Good ThingTM. Our public (perl programmers, coders, lovers and fanatics) feels this like a natural language and just don't care if he/she is writting plain english or using the HTML subset. Given the technical level of great part of our posters, this is a feature: we can format and publish nodes in a simple, intuitive and fast way, without adding lots of complex editor-emulation code to PerlMonks engine.
I would love to read your own feelings and opinions on this matter. Thank you very much for your wisdom and insight about this subject.
XML. It's a good thing. It's general, and controllable. HTML is for a specific purpose.
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.
On one hand, the expressiveness of HTML is nice. On the other hand, there are many ways to do the same thing and I'd prefer never having to filter out JavaScript or CSS tricks or to edit in tags.
For my next site built on Everything, I plan to use a Wiki format. That should provide the most-used formatting in a controlled environment.
Greetings, chromatic.
I guess you see more disvantages than advantages on using HTML as the publishing language. What is the difference from HTML to a WikiWiki like format? You will need to learn the tags anyway. Is the learning curve smoother than the HTML learning curve? Even seeing HTML as a wide-spread tool?
The difference is that you don't filter--you convert. If you use an HTML-subset, you have to check for a multitude of different things, many of which may have only been mentioned in one sentance of one paragraph inside a whole heap of documentation. Missing one means that something you didn't want got through.
If you use a specifically-defined format (UBB tags come to mind), you get to specify exactly what goes in there and anything else is simply invalid. In this case, you can escape any HTML in the data (which is a lot easier than filtering specific kinds of HTML).
----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.
Thank you, fellow hardburn. This is a nice point of view. But, as stated at the begining of the thread, I'm interested on the user's point of view, not in the application PoV.
So the question stands. What you think is easy to learn and use, under the user's perspective?
May the gods bless() you for sharing your wisdom with us.
Your average Perl Monk will have some HTML-foo, so it makes sense to use HTML from that perspective. My personal dream is that one day we'll be able to post with POD. However, this site specifically targets programmers.
If you're targetting less techincally-inclined users, you probably want to stay away from HTML. Some UBB-based boards have JavaScript buttons that will insert the UBB needed for formatting (bold, italic, links, etc.). More DWIMery would be involved (such as finding paragraph breaks). You could ignore the UBB stuff and use simple ASCII markups (*bold*, /italic/, _underline_, etc.); I believe http://kuro5hin.org has a posting mode like that.
There's a lot of possibilities for usability, but few of them require knowing HTML.
----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.
The system I have in mind has volunteers of all sorts of computer literacy levels entering data. I'd rather teach them a few bits of Wiki format to do exceptional things than to teach them HTML to do normal things.
Consider writing plain paragraphs separated by blank lines. (That's very easy to explain; it takes one sentence and people can remember it.)
In the system that expects input in HTML, all paragraphs will run together. You could add logic to turn two newlines into paragraph tags, but that's a heuristic so it'll fail in odd ways sometimes, especially if the user has already added HTML.
In the system that expects Wiki formatting, those paragraphs turn into actual paragraphs, as if the user had used the formatting deliberately.