As some of you already know, many dedicated players reported usability issues with the Eterna Wiki. After careful assessment of the current Wiki, we have concluded that it hosts a few fundamental problem and will need to be renovated.
We have listed the most important problems and proposed solutions. However, before we dive into fixing these, we would like to hear ideas from our players to make sure we going into the right direction this time. If you feel we are missing a fundamental problem, or the solution seems misleading, please do not hesitate add a comment.
Unfriendly url
This has been fixed. The Wiki is now hosted at eternawiki.org.
Speed
The problem comes from the fact that Wiki shares the server space with our Eterna script verification server which is constantly on heavy load. We’ll buy a new dedicated (small) server for the Wiki.
Flaws in style/color scheme
In short term, we will fall back to the “default” wiki style layout/style/color with Eterna logo. In longer term we hope to hire a designer from e-lance to create proper theme dedicated for Eterna Wiki.
Confusing editor / mark up language mix-up (HTML & Wiki mark)
This is perhaps the most important issue we have to address. Currently our Wiki uses WYSIWYG editor which generates HTML code as a result. This was in attempt to provide users with easy-to-use editor but ended up in a big confusion. HTML code produced by such editor is usually ugly and not suitable for collective editing. Moreover, they tend to generate contents with inconsistent styles (looks).
There are 2 solutions. We have not decided which direction we need to go and would love to hear players’ opinions on this.
option i) Switching back to Wiki mark up : This will take a lot of effort, but perhaps worth venturing considering the future of Wiki. We have discovered that there are WYSIWYG editor which generates Wiki mark up code instead of HTML, so we can still preserver “easy-to-use” editor in this direction. Of course, the biggest cost here is conversion of all current Wiki content to the new format. The Eterna team will take responsibility for all the conversion. During that period (which we assume 1-2 weeks), users won’t be able to post new content. We’ll make sure to constantly collect user concerns & warnings about the content before the conversion to make sure we don’t mess up or lost anything.
option ii) Keeping HTML mark up but with strictly organized CSS stylesheet that can “cover” most of HTML elements created by the editor. This will help “regulating” the content style.
Unorganized content
Once the 1-4 are finished, we would like to have a discussion session with players on how we’ll generally categorize/organize/sort content in the Wiki. The best outcome of this will be a “general guideline” to decide where each content should go.
We want to apologize to all who had frustrating experiences with Wiki. Hopefully with this renovation, we will make the Wiki much more usable and become a place where Eterna players can share/discuss knowledge/strategies. Once we get the usability issues sorted out we believe we even can integrate Eterna Wiki seamlessly into lab, group, and many other places in Eterna (that’s bit further down the road though). Again, if you feel we are missing a fundamental problem, or the solution seems misleading, please do not hesitate add a comment.
is already much better than what was before, and I thank you very much for making it happen so rapidly after I suggested it. This said, if it’s not too much trouble, something like
What I find objectionable with the current state of things, is that some wiki-markup gets broken. doesn’t work for instance, neither does wiki-style bullet- or numbered lists. It should not be that way.
Now, HTML can be very nice in situations where wiki-markup is insufficient for a nice visual presentation, and I’d rather keep an open door to the HTML world, specially since it was MediaWiki that was chosen, a Wiki implementation that allows for it. For instance, I’d prefer to keep my little templates showing nucleotides color-coded, rather than being forced to use pics instead.
I’m afraid, any form of “strict CSS styling” is going to have some ugliness in it (are we talking about using !important?)… If you recall my emails Jee, I was thinking that benevolent sysops would be enough to watch over the site, and contact and help newbies to contribute in a cleanly styled fashion.
5.
I think that this is a matter to be discussed between contributors. And if they start discussing such topic, they would (and should) rather do it on the wiki itself
But, for starters, I had envisioned:
Main namespace:
Introductory materials (with wiki contributing, RNA and EteRNA as subtopics)
A reference section, concepts and terms are explored in as much depth as possible
Puzzle solving (walkthroughs in the form of “wiki-paths”)
Probably a section about the labs, past, proposed and current
Groups: I had thought EteRNA groups could organize their meetings, or share their activity on pages on the wiki
and for sure, a coffee machine corner
User namespace:
Free expression platform for players (but still limited to RNA and scientific topics)
And I believe that the information tree doesn’t need to be strictly defined, as long as contributors make use of categorization. For instance, I decided some time ago to create an “EteRNA slang” category. Hopefully, it will help confused scientists to understand what EteRNA players are talking about
Glad to have the wiki off the verification server.
Flaws in style/color scheme
Unless you have experience in design (and good sensibilities), its often best to go with the defaults. Hiring a designer later for minimal work on themes/skins is fine too. Enough to give a flavor and style, but not so much as to detract from content.
Confusing editor / mark up language mix-up (HTML & Wiki mark)
option i) Switching back to Wiki mark up: I tend to be in favor of this, so long as there is an acceptable “escape” for some html stuff. It’s often easier for users to pick up a few wiki-isms than to learn full HTML.
option ii) Keeping HTML mark up. The problem cases come up when the WYSIWIG editor doesn’t know what to do with weird HTML. This can also come up with html breakouts from wiki-markup.
Both options are 90% covered by a good WYSIWIG editor - in which case it doesn’t really matter much what is under the hood, but it’s probably easier when targeting wiki+html (like on getsatisfaction.com), as the HTML stands apart.
Personally I’m in favor of a streamlined environment so people can focus on content rather than layout. That’s the whole purpose of wiki markup in the first place. WYSIWYG+WIKI+some-HTML would be my preference.
Unorganized content
Welcome to wikidom.
Having someone dedicate at least 20% of their time to monitoring + guiding the wiki can help. Also like on Wikipedia, having discussion back-pages can help by giving a place for meta-conversaions about organization, style, etc. Actually a forum style is frequently better for some of those conversations, but it’s also worth it to have the two close together, so wiki pages (with history+undo) can sometimes suffice.
I understand you prefer an editor that uses Wiki mark up as a base, but with some extra HTML support (mostly inline tags that could help you change font colors, etc, but not the block tags that could tweak the overall layout). Is this correct?
This is a great start - and agreed that the tree doesn’t need to be strict. I think it’ll be sufficient to have a “guideline” so that any new user wanting to contribute won’t have to do a blind search to find a right place.
Seems like you prefer the editor with Wiki mark up as a base + basic HTML support (inline elements mostly), which is what ElNando suggested as well. This sounds like very reasonable direction.
Having discussion back pages is a good idea. We’ll have one of our dev monitor & guide the Wiki daily, but it would be better if there is a good guideline (discussed with players) that he/she can follow.
I don’t know HTML. I want to be able to easily add/change an article, and do so without having to jump through hoops. For those that do know how, it would be great for them to have a good interface to work with, but I don’t now enough to add my opinion.
I like Nando’s idea. It will just have to be something that gets worked on as we get there.
