You can still access the full nuts-and-bolts dashboard via a drop-down menu, but it's deliberately harder to find, and editing happens in the simplified area by default. I've recommended WordPress.com accounts to a few people recently; I was surprised by this change, but they - having never used WordPress - seemed delighted by the simplicity of it. This can only be a good thing, and I can see this working in WordPress.org blogs too.
I run a collaborative writing forum and, newly obsessed with markdown at the time, I figured that since users were mostly writing many paragraphs of text, they could pick up the markdown basics if a toolbar + cheatsheet helped them out. In my head, it was going to be some sort of amazing improvement and my forum community would begin chanting my name as they experienced the splendors of markdown.
Yeah, sure -- the writers could certainly grasp markdown #headers, how two linebreaks become a new `<p>`, and even `()` vs `()` links (with toolbar/cheatsheet help). Great! But nested elements and pretty much anything more complicated were a real monkey wrench or just plain unsupported.
Writers would put great effort into their posts (just like a blogger would), changing colors, right-aligning, center-aligning, changing font sizes. -- Things that markdown just doesn't support without some extending or post-processing that would turn into something far more confounding than the intuitive bbcode you started with.
Everyone just understands:
[center][size="6"][color="red"]My Cat, Mittens:[/color][/size][/center]
[size="3"]Mittens says: [i]"Meow!"[/i][/size]
What did your cheatsheet look like?
Also, other communities that deal with a similar audience had the same problem with Markdown and moved back to BBCode. For example, these guys (http://guildwork.com/forum/threads/4e46f3d5205cb22721000765-...) moved from BBCode to Markdown and then ended up moving back and writing their own BBCode parser in Python.
Markdown is good when users have limited syntactical/formatting options. But BBCode makes it easier to extend features with an intuitive syntax that nobody seems to have trouble with.
One example would be Markdown's dependence on character glyphs:
I am currently writing a forum CMS (http://pygm.us/IbkgNZ4d), and I, too, have wondered how to expand the number of tags within a rigid nomenclature. Using a lexer that automatically converts links to tweets and YouTube videos to embedded scripts seems like an unintuitive solution, but on the other hand, people unfamiliar with the commands will automatically display the embeds in their posts.
For commands that don’t convert links, I was thinking about something like ':<COMMAND>:' with an expandable list of whatever people prefer. Something Awful already use this model for their emoticons, and it could be extended to things like images in general like states for election conversation and such.
I have always found the `[url]` solution to be incredibly bothersome and to some extent unintuitive, and with the advent of mobile devices, letting people write their posts in as few characters as possible is a big advantage to be taken into consideration when weighing the pros and cons.
Lots of vBulletin forums use the `:<string>:` syntax because vBulletin's default smilie set ships with that form of syntax (even though you can use arbitrary strings like setting "lol" to display a laughing gif) so everyone just piles onto it. Basically, direct string replacement seems to be universally understood by all users.
But the real riddle here is devising a syntax superior to bbcode that transcends string replacement and does things like take arguments and act like functions.
Because, it's this less-straightforward symbolism that requires the higher order of savviness/pattern-recognition that less-experienced users struggle with. Like `!()` turning into an image (but not `! ()`) or why you'd need to indent 4 spaces to resume a bullet point after an empty line.
In other words, where you and I may find it obvious that we're conforming to the rules of a parser (on some back-of-the-mind intuition at least), I found that this concept of mechanical recognition is nonobvious to the user archetype that expressed confusion over Markdown. To them, `! ()` doesn't work because of a negative rule "there can't be a space", not because the token is simply no longer recognizable to the robot behind the curtains that renders their post. That's the crux I've arrived at that makes Markdown suboptimal for my particular community demographic.
The final point I discovered is that users almost always use the toolbar button for anything that comes from their clipboard (namely image and website URLs). Click, paste, and done. Even on smartphones. So essentially all Markdown did there was take cumbersome syntax that was seldom typed-in to begin with and replace it with less intuitive syntax for a benefit that was seldom awarded: being easier to type! Users then had to confront the `()` beast when editing posts or modifying their post's layout.
Fun stuff to ponder. It's always extremely eye-opening and humbling to be so wrong.
Moreover, I can teach people Markdown 10x faster than I can teach them CMS-specific HTML rules. Moreover, WordPress's TinyMCE stuff can break quiet easily (we have to disable it for most of our writers, I'm still allowed to have it because I never use it), so having a readably syntax AND having an instant-preview seems pretty perfect.