Feedback Thread: Technical Development of a better Mission list

Please observe the most recent version of Sandbox and provide feedback on the project. The goal is to clean up and organize the mission page and the list of missions page.
As many of you may have noticed, we are finally trying to make mission pages. Wow! Better late than never I guess. The improved list we develop now will eventually have working links to all of them.
The template used in the sandbox has flexibility for danger/event/prestige missions in the code.
It features sortability into subtypes, in case the player wishes to only investigate combat missions, or is curious about dialogue and brushing up on lore or something they missed. I know many players likely rushed through all the dialogue missions as quickly as possible, and like to go back later, but don't necessarily want to do so in game for various reasons - and some lock after a single play anyway, or are not available for new users who desire SPOILERS. Or even users from long ago who refuse to complete rank missions ;P. User: Ciardha is helping enormously in the area of NPCs and dialogues, many thanks.
The keyword column utilizes CTRL+F. Users should be able to find "that one mission that had Arkus in it" quickly this way.
The table has a built-in "reset to default order" when sorting by group.
===============================================================================================
Right now, I'd like to focus on the display and finding of rewards. This is mostly for the curious user, because as a player, I don't see why you wouldn't just go after all those goodies, and you can't skip forward to them because missions unlock as you go. So the list would mostly be useful for "oh, I wonder how many missions reward recipes, and I'd like to check which recipes those are real quick so I don't buy them early" and so on. So keeping that in mind, a few format options:
*Binary List, somewhat repetitive entry: yes/no for item types, then reveal the specific items in the showhide
:Good: simple and fast sorting for general search
:Problem: searching isn't as easy. Solution is more columns for rarities perhaps, these seem to be the most desired searches. A Column for FCs, SoLs, Orbs, and Misc Items (evo cats). Will increase table width somewhat.
*Binary list with images in the reward columns:
:Good: very pleasing. Can have quantity information in tooltip.
:Problem: longer page load time for many images.
*Somewhat more repetitive entry: type in a shorthand for the item types, like RFC = Radiant Fire Crystal, SoL = Spark of Life, etc, and reveal the specifics (quantity) in the showhide.
:Good: can use showhide, CTRL+F
:Problem: Hard to do consistently, lengthy list for some missions, clutter
*Simply list the rewards in a linear fashion, like keywords, but with the visual icon linking
:Good: can use CTRL+F, no showhide issues.
:Problematic: horizontal table expansion, vertical cell expansion (ugly), visual clutter
*Bulleted List per row: not really an option for compressed format. Forces vertical stretch. If we add mission card images, this would look okay, but more images = more load time.
Thoughts on this project are much appreciated. As always, make sure you are viewing the most recent version of the page by editing, not changing anything, and saving.

Went through a few versions of entry with a lot of "maybe this, maybe not that," and came up with A and B in the sandbox. I think B serves everyone's best interests. There is of course a lot of work ahead.

What about getting rid of individualized columns alltogether, simply letting it be a showhide?
My thoughts are: users are far, far more likely to investigate the wiki page of an item they plan to get than a mission list page. The acquisition information there (assuming, of course, that us lovely editors have entered it) should state that it's a mission reward, if it is one. I think we'll need to update the rarity page a bit, but that's not crucial because rarities do not behave like recipes. Ugh, why can't we just have a safeguard in-game that prevents a player from buying a recipe (that will end up being bound, of course, not Basil haha) if we have it learned already? It just doesn't seem like knights would have this memory problem if they can "learn" so many recipes in the first place. But that's a different issue than buying something you'll earn later...I guess an ultimate solution to this would be to let vendors buy a recipe as long as your knight has learned it for the exact vendor sell price, bound or not. Wait, which forums is this again? Right, wiki editors, not suggestions.
By the way, a large acquisition project is being built (slowly)- check it out here.
I'd like to keep the rewards column, just the showhide, and remove the others. This also allows easier, non redundant templating of the rewards information, since the rewards show up in more than one location on the wiki with this format, and they are subject to change (they have a few times in SK's history).
In the meantime, we are working on general entry (which can be tweaked, and is being discussed in this thread) and gate maps as well as exploration and individual mission pages. weee.
EDIT: Yeah, I'm really liking the appearance of the most recent version of "Option B (OLD LINK REMOVED)". (Please note that not all entries are complete).
EDIT: the "option B" format has been published here and the above link no longer applies, as it was to a temporary sandbox page. Entries are still being worked on and the format can still be tweaked as desired. The "List of missions" page will remain isolated until entries are complete, after which it will be linked to on various relevant pages.

The page you linked with "Option B" looks good. Show/hides work well here. Option B is looking much better than I expected.

Lists for the non-rank mission types will begin soon, and be mostly the same.
Yes, the list of missions could use work. Listing each mission reward is definitely more for curiosity than utility, for the reasons you mention.
The difference between A and B is text vs. images? And the difference between C and D is text vs. images? Maybe I don't understand D.
If I understand correctly, A and C sound best to me. If A delivers non-insane widths, then it sounds best. But probably it will make tables very wide, so C sounds better. Hard to say until we prototype it. And then you and I might disagree about width anyway. :)