you are bound to think up some good ideas worth implementing,
but a fallback makes things complicated, forcing you to tackle it a different way.
It is also inspired from a reading in which scientists published successful experiments instead of failed experiments;
failed experiments could've provided info for aspiring scientists to tackle problems differently.
Why not let me share my misfortunes, brain drains, and letdowns of trying to execute the ideas to the world
so that others can learn from my attempts and execute their own?)
Tables[edit]
1[edit]
- The proposed map and info table for Battle City's Stages section from the Walkthrough page (2013 July 22) – The table must consist of the image of the map, the stage number (with a name that describes how the map looks), difficulty, and the number and type of tanks they'll appear in the map. After some planning, and a lot of size tweaking, this was the intended result:
Stage 1 | |||
---|---|---|---|
★★★★ | |||
Basic | Fast | Power | Armor |
There are two things prevented me from doing this:
- It's too tedious to insert the desired info into the tables properly.
- I realized that after watching a YouTube video of a playthrough, they're not how many tanks and what types are there, but sending out number of tanks by type and in groups linearly.
Additionally, I spent too much time preplanning and trying to make it work when it was simply overcomplicating things.
Because of these unfortunate consequences, this is the final result. It's much more simpler to handle. Even though the text info and images are completely separated, it makes the info simpler to read and more focused. Alternatively, users won't spoil themselves if they only wanted to read the text info, and not look at the image maps. Unfortunately, for image-only users, they might run out of luck as they may accidentally see image maps that they didn't see before (maybe an extension that covers the whole sections blank unless clicked?).
2[edit]
- The proposed table for Game Dev Story's Grid view section from the Walkthrough page (2013 July 29) – the table I thought in my mind was more ambitious than the final version. Not only it included the ability for the table to scroll horizontally so that content wouldn't spill to the right, it would also make sure the "Type" column would stay in place. With some trial and error, unfortunately, I failed to execute it properly. This is the failed result:
(I added outer specific coding to make sure the content doesn't spill to the right, it's still buggy; this is not part of the failed result)
|
|
Three things for failing to execute this idea:
- The "Type" column wouldn't stay put; if you remove the outer specific coding (that wasn't part of the failed result), and previewed it: there is no scroll section at all, and the inner specific coding is rendered null.
- Due to the fixed width the wiki enforces, I cannot make the table neat by addressing a specific width to the columns.
- The most important of all, even if 1 and 2 are resolved, the sortable input wouldn't interact with the "Type" column at all; those two are separate tables. Having sortable it only applies to it's own table, not interacting with two or more tables remotely.
In a related note, I wanted to make editing on the table easier and reduce space by having variables like: 0 = {{n/a}}, 1 = Not Good, 2 = Hmm..., 3 = Not Bad, 4 = Creative, and 5 = Amazing. However, I had no idea how to implement it all unless an wiki extension is involved.
Because of failing to execute this idea, this is the final result. When scrolling right, the "Type" column is hidden away from the left, requiring to go back to the left side again to make sure the info is correct. It is tedious to the user experience for those who want to retrieve info seamlessly without hassle.