I only came to know about Confluence after joining my current company. I was impressed at how polished the interface was, and how nicely the editor was implemented. Users that do not want to learn the particular details of wiki markup, don't have to learn it; that was great. You had all kinds of cute integration with Gliffy. When I discovered, however that it is not possible to view the markup representation of a page, I was dumbfounded.
The principle of a wiki is NOT merely being able to easily edit a page; it is also to be able to have control over the source representation which is being created. You apparently use some sort of proprietary XML format; while I understand that there are advantages, XML is overly fraught with noise for humans -- doubtless, this is why even though you could expose your native XML and allow it to be edited directly, you don't.
That is WHY *real* wiki's base their syntax on something resembling plain text; it is markup that is, yes, easy for humans to create, but also, the results of transforming it into a display representation is PREDICTABLE and INSPECTABLE. WYSIWYG was an important principle for a single author to create documents intended to be printed; it does not override all other concerns when it comes to collaborative publishing.
In the current instance at work, you are hiding from me the structure of the documents I am trying to create(!), and making it much harder for others to profitable modify that creation (they can't inspect it, only see the result of rendering). Functonally, this is identical to requiring that:
1. Every user simply use, say Microsoft Word to create documents
2. Upload them to a shared file store.
Better in fact: I can still edit RTF documents in vim, if necessary; I don't even have that option with your product.
So what problem does Atlassian think it's solving for it's customers by taking this approach?
I take that no customer actually demanded that you store their markup in XML; the XML markup solves Atlassian's problems better than it solves the problems of customers.
Why not allow your customers to choose what they want? Obviously (since I've been trolling on your support site) I'm not the only person who feels there is a serious problem with the approach you've taken. Your engineers *could* focus on providing abstraction layers that would allow the CUSTOMER to choose the representation format, xml, wiki, yaml whatever: provide a means of defining the abstraction for serialization.
Fortunately, since there are several free alternatives for wiki stacks, I will be recommending that our group standardize on mediawiki -- not because it's easier to use, but because it has the required features, and it is free from a for-profit business who believes in removing those features because it's inconvenient for THEM, at the expense of their CUSTOMERs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.