Talk:DoomEDIT Categorised Key Bindings and Mouse Controls
From modwiki
Contents |
Discuss the list here...
Let me know if there's anything missing that should be here, esp. and of the mouse controls that we missed! Hope some of you find this useful, and I apologise in advance if I made a 'wiki faux-pa' in anyway, this is only the second time I've ever added anything to a wiki, and that was a damn long time ago!
I can be IM'd on the forum under the username RitchieTheBrit. -RitchieTheBrit
Good start
This article can sure be a nice addition allongside of the original list. The only thing I should comment about is the use of HTML code. I'll see if I can sort it out sometime later. -Kamikazee
Continuity and Design
I understand you being kind of cautious about making what might appear to be serious changes to an article but, I'd rather not see two articles that cover the same topic because it's both redundant and can lead to discontinuity where one article gets updated and the other gets neglected.
It would be much easier for everyone if you just edited the original article. This way people don't have to ensure that updates to one article are applied to the other.
The same point could be made about placing both sorted lists in the same article. I'd much rather we just settle on sorting the list one way or the other than try to maintain two lists.
Also, I see you used a lot of HTML where you could have used standard wiki markup. My main concern here is that wiki markup is more like a written/spoken language. Most of the articles you see are for the most part plain text. It's very easy to edit and by using HTML you've essentially limited edits to people who are well versed in HTML. Those who don't know the proper HTML markup won't bother to learn it and IMHO, they shouldn't have to.
All in all I'd like to keep HTML use to a minimum. I envision if we started using it liberally all over the wiki people would spend more time trying to make pages look pretty than filling them with content.
We can always change the CSS properties to pretty up pages later. At least that way, if people stick to standard wiki markup, one change in the CSS properties will apply globally across the entire wiki.
At any rate, I appreciate your efforts. We could certainly use more help. I just want to make sure we're all on the same page.
--Rich 01:13, 15 April 2007 (CEST)
Coolio...
No problem Rich. The only reason I used HTML was because I had already done a webpage using the stripes to make it easier to read, than, and I have NO IDEA about the wiki markup! ;)
Hey, even if the formatting is removed, there's always the PDF version! I'll strip the HTML out of this, and use standard wiki markup, then replace the other article. I realise now how easy it is to revert if people aren't happy! I'll make a backup of it anyway in txt file just in case.
EDIT: Damn, tables in wiki are a pain in the a*se! I may have to take my time over this!
I guess thats it done?
I've removed all the HTML, read god-knows how many wiki articles, mucked around for a good few hours, but I think it's looking okay. Personally, I still prefer the way it looked with HTML, though it would have been a real pain in the a*s for someone who couldn't read HTML to edit.
The only thing I'm not overly happy with is the valign tag. For some reason that can't be included in the style definition for the tables, so it had to be done on a row-by-row basis. It reads better, but it makes the wiki markup a little heavier than I would have liked.
Each row is on the same same line, making changing entire entries a lot easier, and will remain stable as long as the pipes are left in place. Hope this fulfils the requirements of wiki editing! ;) Hey, at least I'm learning something new!
Revision
I've changed this article quite a bit so I'll take the time to explain what I've done and why...
I removed the mouse acronym legend. I think it's safe to say that people should know what RMB, LMB, Wheel and such mean. At least in the context of a command list.
I've also reformatted the tables to keep formatting and content as segregated as possible. If setting the properties of individual cells means staggering the actual content of the table with cell properties... Well it's just not easy on the eyes trying to edit that.
I also changed the fixed widths to a series of percentages instead. This way the tables make efficient use of screen resolution.
I tried to resolve the issue of multi-line cells by shortening the offending descriptions and using footnotes to supplement them. Unfortunately they don't seem to work here so I fudged it by using superscript and asterisks. Clever? Meh. I'd rather use footnotes.
--Rich 12:26, 16 April 2007 (CEST)
Wow! BIIIIIIG Change!
Looks good Rich! Cheers!
I was going to convert all the columns to percentage, but when I tried resizing the window, the columns adjusted themselves anyway! It must be the way wiki presents the html to the browser?
But it DOES look a lot neater, both to read and edit. It hits me as absolutely bizarre that the wiki is designed to be edited by joe public, but relies on a markup language to get good looking results. I mean, even now, I think some people would be put off editing just because it looks a little 'techie'. I know there's been some progress in WYSIWYG editors for wikis, but TBH I would have though that should have been one of their goals from the outset. Have you ever turned on the markup mode in Word? Most people haven't because they don't NEED to see what goes on in the background, and thats the way the wiki's should be. Except, they should work properly. Unlike Word. ;)
