Forum:Standardized terminals layout

From The Vault - Fallout Wiki
Jump to: navigation, search
Forums: Index > Wiki discussion > Standardized terminals layout
 
Gametitle-Wiki.png
Gametitle-Wiki.png

Given that there's been a bit of a controversy lately, I propose establishing a standard terminals page layout. These would be amended into the standards of the wiki. Tagaziel (talk) 08:39, 24 December 2015 (UTC)

Proposal (Tagaziel)[edit source]

  • All pages transcribing terminals from the game are titled terminals, rather than terminal entries.
  • Generic terminals are split from location-specific pages in the manner seen here:
    • All generic terminals found at the location are itemized at the top, using a bullet list.
    • All location-specific terminals found at a given location are transcribed in detail below, using standard wiki markup.
    • Exceptions include control terminals unique to the location, such as the Salem turret terminal.
  • Terminals are formatted according to the following layout:
==Terminal name==
;Creation/GECK Kit ID: 
{{small|Location and other notes}}
{{transcript|text=
Header
}}
===Terminal Options===
{{transcript|text=
Terminal Option transcript
}}
  • On location pages, terminals are listed with a link to the general terminals page at the top, followed by any named terminals present. Terminals lacking unique names are not listed, due to the impossibility of linking to them.
  • Use the following code:
|terminals       =[[Location terminals]]:<br/>[[Location terminals#Uniquely named terminal|Uniquely named terminal]]<br/>[[Location terminals#Very uniquely named terminal|Very uniquely named terminal]]

The Current Standardized Format[edit source]

  1. All pages transcribing terminals from the game are titled terminals, rather than terminal entries.
  2. Terminals by Location is the format, with Generic terminals transcribed into each page that utilizes them. Separating pages is completely unnecessary, creating unnecessary page bloat. Implying to not link terminals because they are not uniquely named is simply ridiculous. The vast majority of terminals are generically named and all linked appropriately in all Fallout 3 and New Vegas location pages.
  3. When multiple terminals reside within a building in a settlement, it will be located on that buildings page. However the whole article will be linked in the settlement's main page. See Megaton as an example.
  4. All terminals are to be placed within the article with a first to last approach. For example those closest to the main entrance would be first, then proceeding to main exit, unless they are generic. Then they would be merged into the topmost terminal, with the "Notes" section describing each individual terminal.

This is the format that I have spent at least three years standardizing. Meticulously checking each entry for errors.

  • The Full Terminal Name as is in game, with absolutely no de-capitalizing or spelling corrections. It is to also be used with the 2nd level heading.
  • The Notes section(s) on where the individual terminal(s) are located, what kind it is, and what its Hacking level is. These section(s) are to be placed underneath the Main Header for that specific terminal(s).
  • The Content of the Terminal Entries - Must be a Direct copy-paste from the GECK editor!
  • The "loading notice" (term I'm using) must be added below whatever is being accessed with a > to differentiate that it is NOT part of the loaded text. Must also be a Direct copy-paste from the GECK editor, not all are the same either!

The Notes section for the terminal entries pages is for Notes about the page's content. Misspellings, grammatical errors, lore errors, et cetera, within the content are to be mentioned here.

==Terminal 1==
{{Transcript|text=
House Industries Network

Not Welcome /< USER
}}
===Example command.===
{{Transcript|text=
> loading...
}}
===Example Entry 1234===
{{Transcript|text=
Bla bla bla bla bla
}}
{{Transcript|text=
> loading...
}}
Wait, what? You've been going over the location articles and adding "Terminal, Terminal, Terminal" to the infobox without consulting with anyone else? Where was the standard you're using discussed? Who did you ask about it? This is a major formatting change and one that looks incredibly bad to anyone who visits the viki. I mean, how in hell can you consider having EIGHT SEPARATE LINKS to the SAME ARTICLE saying TERMINAL better than one uniform link? Tagaziel (talk) 11:57, 24 December 2015 (UTC)
I've asked a long, LONG, time ago. Also Each of those Links goes to a UNIQUE Terminal.--12:14, 24 December 2015 (UTC)
No, it does not. Every link goes to the top terminal. I've also gone through my talk pages and there's nothing in there that mentions such a broad change to the formatting.
Furthermore, your constant reverting of my edits and outright vandalism (removing content, i.e. Creation Kit IDs, from terminal pages) is extremely disruptive. Don't make me invoke sysop privileges and demand that you stop. What additional value does repeating the same text across a hundred pages provide that a simple link does not? And tell me, in what universe does this:
Terminal
Terminal
Terminal
Terminal
Terminal
Terminal
Terminal
Constitute something easier to navigate than this:
Vault 34 terminal entries
On what basis do you claim the end user will know which terminal they need? You provide seven links to the same page, ALL SAYING THE SAME THING. This is poor editing.
So stop it. Tagaziel (talk) 12:25, 24 December 2015 (UTC)
User:Ant2242/sandbox01#Terminal_entries_project

Here. EVERYTHING on this project. Critique away.....--Ant2242 (talk) 12:30, 24 December 2015 (UTC)

There is nothing on the page that implies any kind of formatting changes - least of all the ones you were implementing. Nothing that says you should include seven instances of Terminal one after another, linking to the same page, or disruptive removal of Creation Kit IDs.
This is why I propose a single, unified format which we will first apply to Fallout 4 and then to preceding games. Mostly because the terminal entries are taken straight from the game files. And I also mean to save you work and annoyance by having a proper layout agreed upon. So, agreed? Tagaziel (talk) 12:46, 24 December 2015 (UTC)

Except for the example shown... The "Creation Kit IDs" should at lease be placed within the notes section as to separate it from the Gorram Terminal transcript. (btw I've never removed them.)

The real annoying thing is how both you and GB tend to miss the wholes in the data when adding source texts. Whether its formatting or a bot error due to it being within either a greater/lesser-than sign or a quotation mark. I've always had to check.--Ant2242 (talk) 21:36, 24 December 2015 (UTC)

Votes[edit source]

Paused pending discussion. Tagaziel (talk) 17:28, 19 January 2016 (UTC)

Tagaziel's proposal[edit source]

Ant's proposal[edit source]

I want to make this very clear, my proposal is to keep the standardized format as-is (minor updates as necessary). Complete, concise, and accurate to what is in game by location.

CompleCCity's proposal[edit source]

A comment[edit source]

I have to admit that it's by now very difficult for me to differentiate between the two proposals. I don't really have an imagination of the differences between the two code formats, what it will look like later and if there's really a difference. My thoughts: let them look the most similar to the in-game appearance like possible.

I'm no friend of the practice I've stumbled about of linking several entries "Terminal" in the infobox, those should be distinguishable, by more detailed location for example. (Perhaps like the notes in brackets behind different cell names for the same location.)

I too have a problem with the proposal of ordering the entries by appearance in the location. Do we go left, do we go right? What with not so linear local maps, with many corners, turn-arounds, such things? I would prefer an ordering by either the names, alphabetically, or by the ref IDs (you know, with use of the console one can find out, which terminal exactly he's staring at, so why not listing them).

A note about general terminal names, in the world and in the specific location:

  • A terminal called simply "Terminal" can have different entries in Rivet City and in Megaton.
  • Additionally two terminals called simply "Terminal" can have different entries even on the same local map (see H&H Tools Factory).

As I understand Tagaziel's proposal right those should all be listed on the same page, a general overview. Not practicable. Or am I wrong?

  • What about the practice of creating subpages? Why not moving – to stay with the given example – H&H Tools Factory terminal entries to [[H&H Tools Factory/Terminal(s)]]? (I'd prefer "Terminal(s)" rather than "Terminal entrie(s)" – plural only where there are more than one.)
  • Then one entry for each name of appearing terminals, in the given case there would be 3 entries (named "Anthony House's Terminal", "Suspicious Terminal", "Terminal") rather than 10 entries with often the same names. The shared notes should then be listed below each of these entries.
  • Then sub-entries with specified location/description for terminals that differ from the usual ones, that have more or different notes.
  • Example:
    • [[H&H Tools Factory/Terminals]]
    • ==Anthony House's Terminal==
    • Note: This terminal can be found…
    • TERMINAL NOTES
    • ==Suspicious Terminal==
    • Note: There are a total of x, which share the following notes:
    • TERMINAL NOTES
    • ===Suspicious Terminal (1)===
    • Note: This terminal can be found…
    • TERMINAL NOTES

Only my ideas, not very reflected at the moment, and a short and quick opinion. For now, I can't spend more time on this topic, but there are two days left for the poll. ;) -- CompleCCity (talk) 13:19, 18 January 2016 (UTC)

Found some time, so I've created an example of a restructured H&H TF T entries (to stay with the example). This doesn't reflect layout changes in how a specific entry would look like, it's only about restructuring the whole original site, making it – in my eyes – much more easy to navigate. Also it'd remove redundant content.
If we are to remove the "redundant" information for each different terminal that would be editing the source document itself. In doing so we would have gone full circle and back to the original format. Everything haphazardly added by typing with no regard for accuracy or explanation. If so then calling all the pages "terminal entries" would be accurate again, as it wouldn't be the terminals as presented in game.--Ant2242 (talk) 15:00, 18 January 2016 (UTC)
I'm not sure if I understand this right…
By now on the location specific terminal articles each found terminal is listed, not specified by Form- (Base-), REF-, or EditorID. Then all notes for each instance are added, with a template {{Transcript|…}}, containing the source text, copied from the GECK or the raw data pages. No transclusions here.
So what's the source document you're talking about?
If we were to use sources, then we could reorganize the raw data pages, creating an unformatted note for every note from the game (though inserting unique links where possible and recommended), based on its EditorID. Further creating templates for formats of holodisk-notes, paper-notes and terminal-notes (if they don't exist already, haven't looked after that).
Same for the terminals: creating an article for each terminal by its EditorID, formatted to look like in-game, citing the greeting and including the server information. The contained notes could be transclusions from the formerly created ones, formatted appropriatly.
For each location then an overview of the terminals, ordered by name (because that usually is what at least I am looking for when searching for information on a specific terminal), but including every FormID and REFID, so there would be multiple instances for some models.
For the sake of readability: It's not easy to find the information I'm looking for, when on this overview page there are seven entries, each one called "Terminal", each one listing the same three e-mails, with each time the complete text – and somewhere there's hidden an additional entry between all this clutter. So why not placing the header, the title of the note – firstly as link, secondly as transclusion, but collapsed. (That's btw the same way, the game is working: A terminal has specific formattings, but the notes are only references.)
And sorry, but I don't have real ideas about the original format and circling around – I haven't your experience with such things on this wiki. Again – only my two cents. -- CompleCCity (talk) 16:01, 18 January 2016 (UTC)

Hey CompleCCity, let me explain with an example:

  1. This is the format I've been generally trying to stick to. All terminals unique to the location are transcripted on the page, with each terminal identified by its name (if available) or function (if it's simply a generic terminal). Duplicates are listed under a single heading, with the notes and ID explaining that all of these terminals share the same contents.
  2. Generic terminals (turret, door, spotlight, Protectron controls and so on) are not transcribed on the page, but are linked to at the top. That's because these terminals share the same options and functionality and are set up as separate, generic terminals in every location.

The intent is to provide a clear picture of which entries are unique to the location given and only providing the full text of those terminals that are unique to the location. It's done for the sake of usability and readability. I respect Ant's numerous contribution, but this is where I'm refusing to yield, as anyone looking up, say, BADTFL terminals is going to be interested in terminals unique to BADTFL, not a text dump of every terminal that's there, including text that's identical across a hundred other pages.

By the way, your input is invaluable. A fresh perspective is always good. Tagaziel (talk) 17:49, 18 January 2016 (UTC)

Thoughts about the given example, the thing in whole, and thanks for the kudos…
  • Linking general terminals to their respective articles I would only tolerate, if references of their base are indeed spread all over the world. In my opinion each location-specific ID should be listed on that location's terminal article.
  • The advantage of using your specific example is, that it only consists of three (the two general ones excluded) terminals at all. So it looks "by default" more clean, more readable than the H&H TF one I used.
    • But nevertheless your page also would benefit in terms of readability and cluttering, if the entries, the notes (technically; there are no "entries", at least in GECK) would be collapsed.
    • Your "duplicates are listed under a single heading", how would that look with my example: 10, in words ten different terminals, but for 9 of them there are three identical notes each – not to speak of only 2 names for 9 terminals).
Shouldn't have looked into the history of your link… What are you doing there, you two? At least 7 undos by both of you, Ant and Tagaziel. Nothing better to do with your time?
But this way I have a good opportunity to compare your layouts.
  • First: I don't see any difference in the layout of the terminals itself. Wasn't there proposed changes, too? The text color for example?
  • Your version, Tagaziel, looks less cluttered, the TOC has unique headings.
  • Not so with your version, Ant2242, where I only can differentiate by the sub headings.
  • But:
    • Ant's layout reflects the links in the infobox, there's no word of some Sergeant's terminal…
    • And I think, this also reflects the names of the terminals in the game. (I don't have FO4, can't check this.) How would I know, when visiting this page while being in that office, which one is that Sergeant's desk or even his terminal, when all terminals I can look at in the room are named "Terminal"?
    • In addition, when his terminal has the default turret controls integrated, then a default tc terminal isn't in the room and those extra options would have to be listed for the specific terminal, like Ant is doing it. For the safe control, he (she?) even links to the default terminal, transcluding those entries. That's not that different from what you want, Tagaziel.
Back to what I as an only-user would wish to see/read when looking after terminals in a specific location.
  1. One link is enough, I don't need several ones in the infobox, some of whom are even named the same.
    1. If there are especially notable terminals, they could be linked separately, not in the infobox, but in the layout section.
  2. I'd like to have the in-game name of the terminal in the listing, not an admittedly descriptive one, but the one I see as player.
    1. That leaves the question how to specify different terminals, that all are named the same, in a way that doesn't distort game resources but is clear, quickly to understand and to find, and can somehow be integrated into the TOC. (Small notes concerning the location don't fulfill these criteria.)
  3. I really would welcome the option, that all notes/entries are named as separate headings, but the whole text should be collapsed. That's not so far from the game, where I also have to choose the topic I want to read.
  4. I wouldn't like cutted entries, only because they are mentioned elsewhere. If I see a terminal in-game with 5 topics, and come here to look after it and find one, that only has 3 topics, then there's something wrong. (That includes redundant things like turret control. And that doesn't object my former remarks.)
That's all for now. Btw., is here some option to link a user, so he knows, he was addressed? -- CompleCCity (talk) 20:58, 18 January 2016 (UTC)
Alright, trying to order the entire response in a sane way. :)
I'm talking about generic terminals because they really are generic. I have the entire TERM tree output from the Fallout 4 ESM in front of me, and terminals are divided into generic (prefixed with native, eg. nativeAssaultronTerminal) and location-specific (eg. MQ102SturgesTerminal). The game then links them as necessary.
The terminal transcripts aren't changed, because they work fine. I'm against collapsing them all for one reason: It adds additional clicks to view the content, which adds up and gets tiresome. I work with terminals pretty much constantly, getting references for articles, and having to open them constantly would be maddening.
Now, the problem with Ant's layout is that it is neither descriptive, nor easy to navigate. Terminal transcripts have to be both, as they are not supposed to be an ideal representation of the game, but a transcript: Transcripting their contents with an easy to use layout. Having ten headings named terminal is unencyclopedic and hostile to the user.
Ant forgets that people who read terminals don't give a damn about whether they reflect the in-game naming of a terminal, they want to be able to quickly identify the terminal they want to read through. That's why I do not agree with Ant's insistence on retaining generic naming. If a terminal is in the jail and contains data related to the jail, it should be named Jail terminal on the wiki, to make it easy to find. It doesn't distort game resources at all, as these terminals usually have a Creation Kit ID clearly defining their function, eg. MS17RogersTerminal for Emmanuel Rogers' terminal in Covenant (normally named office terminal).
The most important point is this: People who come to read terminal transcriptions and access specific location pages will primarily want to see entries unique to the location. If they want to brush up on the contents of a particular terminal or were directed to it as a source, they want to be able to find it by accessing the table of contents. Ant's approach provides them with five headings named Terminal and forces them to read through the entire page to find what they want or use Ctrl+F - both of which will usually cause them to close the tab and look elsewhere. The descriptive approach maximizes ease of use without compromising anything. Hell, do you even remember (or care) whether the Desk Sergeant's terminal you saw at one of the ten or so police stations in the game six hours ago was named Desk Sergeant's terminal or simply terminal? Obviously, this makes listing terminals in the infobox easy and self-explanatory.
As for cutting entries: Nobody argues cutting them. The point is to minimize clutter on the page by linking, rather than repeating the entire text six times across the page. Ant doesn't seem to mind, but anyone forced to read through six instances of the exact same text for door or turret controls is going to be greatly annoyed - especially since they do not add any value that can't be done with a link. Tagaziel (talk) 12:59, 19 January 2016 (UTC)
I kind of do not want to settle with the lesser/greater evil here, as I feel that both of you have good points. I do think that Tagaziel's points are stronger, especially in regards to 'Terminal' links appearing over and over and over again, without any sort of designation involved, which leads to a very unprofessional and cluttered look that is completely unnecessary in my eyes.
So I am hesitant to vote at this time, because I feel strongly that this is a scenario where a proper compromise can be reached. I will keep an eye out on this forum, and update my opinion where necessary. GarouxBloodline 22:03, 18 January 2016 (UTC)

New thread, separated for clarity.

As you have pointed out the format (the one that I have standardized the wiki with for years), it includes all that each terminal displays with each wiki header being presented within the Table of Contents tab. I know that removing any "redundant" information is tempting for "brevity", however this would carve away lore from the page, and we must keep it as accurate to game as possible. Unfortunately, (as we all know) the generic naming convention can be tedious to look at, however this seemingly unnecessary generic convention is a product of Bethesda and therefore we cannot change the name of the terminal.

To further explain the format it basically boils down to this; What Bethesda/Obsidian wrote, from the very name of the terminal, through their spelling, grammar, headers, closers and so on, must stay exact as in game. Only identical, completely identical, terminals can be merged. What do we edit you ask? Only the links on the page, and the sections detailing what each specific header and/or transcript is. Specifically, what a command does, when special parameters are there for entries, and a description on the location and hacking status of the terminal.

Onto the subject of linking, we now have a reference policy which accurately links to each specific section. The arguments I have heard is that the generic named terminals in the infobox looks bad and one has trouble finding an individual terminal among them. When I added all the terminals to the infobox I used the current format for our Fallout 1 & 2 terminal names display. If we are to change this it must still reflect the in game name somehow. --Ant2242 (talk) 23:20, 18 January 2016 (UTC)

Keep in mind that there is a huge difference between changing the transcripts themselves, and changing our links to them, or tacking on a footnote/similar, for clarity. GarouxBloodline 01:17, 19 January 2016 (UTC)
Why do you insist on obsessively adhering to the game when it hurts the usability and legibility of the text? You seem to forget that we are here to offer a service to the end user and that service needs to be friendly, easy to follow, and well organized. What you propose is neither of the three.
  1. Nothing of value is lost when you replace a generic terminal with a descriptive, accurate name. It improves readability and navigation. There's literally no reason to do anything different. Hell, you even agree that it's better.
  2. Removing generic text shared across a hundred locations in favor of a single link doesn't carve away any lore from the page. It improves readability and navigation - if someone wants to know how the generic Protectron terminal looks, they have a nice, clean link at the top. User experience trumps all.
  3. Finally, why can't we change the name of the terminal? We are here to provide a coherent, compact overview of the contents of terminals in each specific location. We are, by definition, editing the contents to make them readable and understandable. We can't - and we shouldn't - try to recreate the game here, because that's not the point. The point is to give the end user a clear overview of the contents of a terminal unique to the location and link them forward if they want to read what other contents are there.
I won't repeat the entire argument, as it has been posted above. Tagaziel (talk) 12:59, 19 January 2016 (UTC)

And another.

I have new questions:

  1. What is the intent of listing the single topics accessible on each terminal in the TOC? Wouldn't it suffice to list the terminals only? (Don't ask, why…)
  2. I don't get the point of The Vault:Raw game data/FNV terminal headers and closers, when the terminal transcripts don't transclude this page, but all text is copy-pasted newly onto the terminal's pages. Therefore I don't understand the sensitivity of the whole transcription thing. Could someone please explain to me?

-- CompleCCity (talk) 11:29, 19 January 2016 (UTC)

  1. Each header of the transcript is itself a transcript of the command of the in-game terminal. For example "===> Disengage Lock===".
  2. The issue is because of confabulation. When someone types something they saw they may inadvertently change the content. Although it must be said that all the headers and closers on the pages have yet to be checked with that materiel. (Due to the release of Fallout 4.) Also that page in particular is not wikified.--Ant2242 (talk) 12:22, 19 January 2016 (UTC)
Confabulation is a non-issue. Never, not once, did this happen. It's a problem that doesn't exist and non-existent problems shouldn't dictate how we approach the wiki. Tagaziel (talk) 12:59, 19 January 2016 (UTC)
The TOC is generated automatically by the wiki software, since we use level three and four headers for separate entries. Unless we change the entire system (which is pretty much impossible), it's just a convention. I like it personally, since it allows for quick linking to just about anything. Could be better done for LOOOOONG pages, though.
That's just a reference, a dump showing a listing of all the terminals in the game together with their options. Transcluding from that page is actually tougher than just copying the appropriate header onto the terminal entry page.
Finally, it's not a sensitive matter for all but one. Tagaziel (talk) 12:59, 19 January 2016 (UTC)
Okay, many opinions, many points, now.
  • I will give two examples, I did fiddle around with. Links further below.
For the naming of terminals you have good arguments, Tagaziel, but because I am of a kind that likes to stay with the original, I certainly understand Ant's view of these things. (I even wouldn't de-capitalize locations and such, because that's deviating from the game, from the original – but that's another discussion, or better: not anymore.)
  • In that point some sort of compromise should be worked out, like Garroux already mentioned. In my examples I solve this by on the one hand describing the terminal in a plausible way, on the other hand setting the name, "Terminal" in those cases, in bold letters. There might be other possibilities. Locations with many terminals could get a local map with markings for them, e.g.
My opinion to collapse the single entries doesn't seem to be received well, as you, Tagaziel, are speaking clearly against it, and Ant said simply nothing about it. But I stay with that and can't really comprehend your arguments, Tagaziel … are my examples really that bad?
You too will notice another small change: My "notes" are indented. I know this practice from other wikis, and I like the look of it.
I prefer the second version in my example, looks better, has subheadings, and the transcription looks like a real transcription. The welcome text in the box and the topics itself give a feeling similar to in-game – in my eyes.
To get a better understanding of the differences between your proposals, perhaps you both should rework the H&H Tools Factory terminal entries, this is a really large and cluttered page. Would be a great challenge, and showed the differences best, I think. My examples are taken from that site.
Perhaps you best would open the two links in two windows, to have a better possibility of comparing the original to my two ideas. I don't want to say, my thing has to be done, but parts of it could perhaps be integrated.
-- CompleCCity (talk) 17:08, 19 January 2016 (UTC)
So far, I am liking your example. As a further attempt to mend the divide, it is also plausible to add, under the custom headers, what the terminal is referred to, in-game, as well. That way we can improve readability, while also adhering to the technical data whenever feasible. It will add another line of text, of course, but I would consider this acceptable clutter if it means we can help reach some sort of agreement. GarouxBloodline 17:15, 19 January 2016 (UTC)
I've gone ahead and did as you suggested, redoing the H&H Tools Factory terminals. Here it is. Now, explanations:
  • We shouldn't be trying to emulate or recreate the game. The focus is on the terminals' content, not the way they are presented. Given that the terminals are sometimes disjointed and strewn across the entire location, our priority should be to make them easy to read through and understand. This page is a fine example of why just copy/pasting every terminals' contents is terrible: Given that EVERY terminal contains the three Human Resources terminals, you wind up repeating the e-mails seven times, for a total of 21 additional entries. Compare:
current Tagz'
Contents [hide] 
1 Suspicious Terminal
1.1 HR E-mail 05/14/2020
1.2 HR E-mail 07/25/2022
1.3 HR E-mail 11/08/2023
1.4 Access Hidden Network Drive
1.4.1 Journal Entry 07/12/2062
2 Terminal
2.1 HR E-mail 05/14/2020
2.2 E-mail from Dobson O'Gill
2.3 HR E-mail 07/25/2022
2.4 HR E-mail 11/08/2023
3 Terminal
3.1 HR E-mail 05/14/2020
3.2 E-mail from Alan Dalton
3.3 HR E-mail 07/25/2022
3.4 HR E-mail 11/08/2023
4 Terminal
4.1 HR E-mail 05/14/2020
4.2 E-Mail from Jack Maynard
4.3 E-Mail from Jenny DeSoto
4.4 E-Mail from Alan Dalton
4.5 HR E-mail 07/25/2022
4.6 HR E-mail 11/08/2023
5 Suspicious Terminal
5.1 HR E-mail 05/14/2020
5.2 HR E-mail 07/25/2022
5.3 HR E-mail 11/08/2023
5.4 Access Hidden Network Drive
5.4.1 Journal Entry 04/15/2077
6 Suspicious Terminal
6.1 HR E-mail 05/14/2020
6.2 HR E-mail 07/25/2022
6.3 HR E-mail 11/08/2023
6.4 Access Hidden Network Drive
6.5 Journal Entry 12/27/2074
7 Suspicious Terminal
7.1 HR E-mail 05/14/2020
7.2 HR E-mail 07/25/2022
7.3 HR E-mail 11/08/2023
7.4 Access Hidden Network Drive
7.4.1 Journal Entry 04/06/2068
8 Terminal
8.1 HR E-mail 05/14/2020
8.2 E-mail from Jenny DeSoto
8.3 HR E-mail 07/25/2022
8.4 HR E-mail 11/08/2023
9 Terminal
9.1 HR E-mail 05/14/2020
9.2 HR E-mail 07/25/2022
9.3 HR E-mail 11/08/2023
10 Anthony House's Terminal
10.1 Journal Entry 05/14/2061
10.2 Journal Entry 01/19/2062
10.3 Journal Entry 06/19/2077
10.4 Lucky 38 Executive Override.
11 Cut entries
11.1 H&H Tools Journal Entry 11/08/2053
11.2 Cut science check
11.2.1 Success
11.2.2 Fail
12 Behind the scenes
1 Shared entries
1.1 HR E-mail 05/14/2020
1.2 HR E-mail 07/25/2022
1.3 HR E-mail 11/08/2023
2 Anthony House's Terminal
2.1 Journal Entry 05/14/2061
2.2 Journal Entry 01/19/2062
2.3 Journal Entry 06/19/2077
2.4 Lucky 38 Executive Override.
3 Suspicious terminal
3.1 Shared entries
3.2 Access hidden network drive
3.2.1 Journal Entry 07/12/2062
3.2.2 Journal Entry 04/06/2068
3.2.3 Journal Entry 12/27/2074
3.2.4 Journal Entry 04/15/2077
4 Jack Maynard's terminal
4.1 E-mail from Dobson O'Gill
5 Jenny DeSoto's terminal
5.1 E-mail from Alan Dalton
6 Dobson O'Gill's terminal
6.1 E-Mail from Jack Maynard
6.2 E-Mail from Jenny DeSoto
6.3 E-Mail from Alan Dalton
7 Alan Dalton's terminal
8 Cut entries
8.1 H&H Tools Journal Entry 11/08/2053
8.2 Cut science check
8.2.1 Success
8.2.2 Fail
9 Behind the scenes
Terminal data
Name Anthony House's terminal
Location On the desk in Anthony House's Office.
Lock Average
Header H&H Tools, Inc.

"Building the things you need to build a better tomorrow!" Employee access terminal

Content tree

HR mail 1
HR mail 2
HR mail 3
Journal Entry 05/14/2061
etc.

  • In order to keep the notes section from becoming gibberish, I've added a small infobox that would be used for each terminal and which would contain their in-game name, location, Creation Kit ID, lock level, as well as a link to non-unique contents. That last bit is really useful, as it keeps the main space dedicated to unique terminal contents, without removing information about what they contain. Or we can have a listing of all the entries, with non-uniques linked and uniques bolded.
  • In general, the point is we should strive for readability, ease of use, and minimizing repetition. This is actually a very useful discussion, as it will help reorganize the entire system into something that doesn't look like the nightmarish H&H Tools Factory terminals page. Which is a nightmare.
Regarding capitalization: The years old policy was to decapitalize, for the sake of simplicity. :) Tagaziel (talk) 20:41, 19 January 2016 (UTC)


Looks much better than before… but isn't that far from my first try (which now is only accessible via the history of my sandbox01). Some more additions, like the infobox. Which I haven't understood completely by now: Where will it be placed? (And a short note: Your example for the infobox with links to the shared entries, being the infobox for Anthony House's terminal… That terminal is the only one in the whole area, that doesn't share these entries! ;)
If Ant2242 now would give that page an overhaul, too, we could merge the best of all solutions together. (Which in my opinion is a better idea than a competition…)
Another short remark, regarding that special page: As far as I know this "Lucky 38 override" option is cut content, too. Should be listed there, or at least a note has to be given, that the missing consequence of accessing that command was cut. If I remember right, this is noted on the other two locations with this option. Will do that when this discussion's over.
Unfortunately I have to tell that, starting with tomorrow afternoon, the next few days I don't have the possibility to access the wiki. If there's need, take from my sandbox what you want (all of you), though I don't think, my simple attempts will be regarded by you. ;) By Garroux, perhaps, he liked them.
Oh, and thanks for sharing my opinion of that terminal's page… :) -- CompleCCity (talk) 23:23, 19 January 2016 (UTC)
As I see it this entire discussion is about appearances rather than about accuracy and readability. Our format is with terminals by location because this is the most efficient way of accounting for the terminals is game. Each section is added via the GECK - because without it confabulation will sneak its way in. (Confabulation in this context is someone 'correcting' - incorrectly transcribing - what is presented in game.) Emulating each terminal as presented in game is necessary for accuracy, otherwise we are adding our own content to lore. The content's presentation is very important, I cannot stress this enough.
  • All terminals must be named as they are in game. All headers and terminals must be capitalized when presented, because there are notable exceptions.
  • All terminals must have their content as presented in-game. We are not in the practice of editing the content.
  • Separating "non-unique" and "unique" entries is incorrect, as it edits what the terminal displays. Transclusions of the command entries is another topic.
My new working format User:Ant2242/TERMINALS!
--Ant2242 (talk) 02:16, 20 January 2016 (UTC)
No, the entire discussions is about accuracy and readability. You're imagining problems. Confabulation, seriously?
You still haven't explained why we must do something as it is presented in the game or why we need to repeat content that is shared, word-for-word, across, say, six terminals, instead of linking to it. What you're insisting on is not efficient and it sure as hell ain't readable.
What you don't want to understand is that we are not adding our content to the lore. We are presenting an edited (this editing), that is, a condensed, well organized, and readable presentation of the contents of a terminal.
Seriously, if you want all terminals to be as they are presented in the game, why aren't you insisting that we delete all text content in favor of screenshots? After all, by including only the text, we aren't presenting it as it is shown in the game.
Now, commentary:
  1. You're insisting on removing the table of contents, to make the page even less readable, I guess?
  2. No infobox in favor of an even more bloated notes section?
  3. What is the point of copy/pasting the exact same shared set of e-mails? It obfuscates unique entries and makes them more difficult to read, on top of bloating the size of the page (which is nearly twice the size of my proposal).
  4. You do realize that by adding anything in parentheses, the heading is not the name of the terminal as seen in the game, right? :P
I still don't understand why you think emulating the game is so vital. If you want to emulate, why not screenshot everything? You are never going to be accurate just with text. Tagaziel (talk) 07:13, 20 January 2016 (UTC)
No. It is a real problem, I've contended with it on most 3 & NV pages already, only those add-ons whom don't have Raw data pages are in question.
Because it is as presented within the game. Otherwise why not just use the Raw data page as the content and link directly from/to that? Its legible by your standard and it gets linked the way you prefer.
Something you seem to be ignoring, quote: "We are presenting an edited (this editing), that is, a condensed, well organized, and readable presentation of the contents of a terminal." You admit to editing the content of each Frakin terminal and then emphasis your opinion on what should only be there. If the game has them then its there, Bethesda/Obsidian did it we just verify and utilize.
Good luck with that.
1. There was nothing wrong with the Table of Contents before, but I remember someone thinking it looked bad.
2. The notes section is not "bloated", none of them are.
3 & 4. It obfuscated nothing. Everything is there as presented in game, and linked correctly with references. Like I said before, you like the minimalist approach of "just what you find appropriate" not what is the content of the terminals in game.
--Ant2242 (talk) 09:04, 20 January 2016 (UTC)
So, okay, where do I begin?
First: What I don't like on Ant's approach is taking my idea of collapsing the entries, but then using default "show/hide" options for the access. I like my version with "> Accessing/> Back" way better.
And what speaks against "emulating the game", Tagz? The maps are somewhat similar, and perhaps sometimes in the future we have 3D objects as image in armor infoboxes. For FO1 and FO2 GIFs are used since years. And if it isn't too much work, why not?
I've now done my own approach to the complete page,
  • recalling my Access/Back, even varying it in the CC section (which was my intent, to adapt this to different terminal options like "downloading file" and such things),
  • clustering shared things, but not for all entries,
  • leaving the in-game names, yet describing specific terminals in an appropriate manner,
  • thus shortening the TOC and the page,
  • and leaving all entries for all terminals to maintain the chronological order of these entries (multiples only linked).
  • And formatting the transcriptions in a way, they appear – in my eyes – more clean, with a slight distance to the symbol shown.
Btw, the size of my page is placed between your two versions.
Here it is.
I'll take myself into the votes section… -- CompleCCity (talk) 11:15, 20 January 2016 (UTC)

I'll reply to both in one heading:

First, for Ant, a definition of editing, so that we're all on the same page:

Editing is the process of selecting and preparing written, visual, audible and film media used to convey information. The editing process can involve correction, condensation, organization, and many other modifications performed with an intention of producing a correct, consistent, accurate and complete work.

Second, the issue at hand is readability. It always was. People visiting terminal pages are not interested in seeing the contents exactly as they are. They want an overview that's easy to read, logical in organization, and doesn't repeat itself. As someone who works with terminal entries pretty much every darn day, the current set up (basically, Ant's proposal) is completely counter-intuitive. The only thing it has going for it is that it looks kind of like it does in the game and that's about it. But when you're trying to find a single source, you have to wade through an entire page of repeated, redundant contents to find what you need. Try finding a random unique entry on the H&H Tools Factory page, without referencing the Table of Contents. Better yet, try finding an entry when you only have a rough idea of what it contained, but don't remember either the terminal name or any particular phrase to look for. You have to wade through terminal upon terminal, reading the contents.

This is what's wrong with emulating the game. By trying to recreate the page exactly as it looks in the game, you are creating a hostile environment that's difficult to navigate and read. This is also where the differences with media are the most apparent, CCC, as static screenshots are an approximation that is replaced as more perfect tools become available. Ideally, we'd incorporate a model viewer, though until these are bug free and don't cause size bloating, we settle for the next best solution. A model would add value, yes.

But terminals? The only added value is that it kind of looks like in the game, except for the lack of font, functionality, sounds, graphics, and everything else that makes a game. In turn, it removes values such as readability, ease of navigation, and finding stuff within the body of the article.

Which, by the way, is one of two things that break your proposal CCC:

  1. By collapsing all entries, you make the entire page impossible to search using the Find function. Try finding the phrase monkey fuck with all the entries collapsed. It's a deal-breaker.
  2. Grouping terminals under a single heading based on their in-game name is confusing and renders one thing very unclear: The H2 heading is very useful to distinguish individual terminals, due to the divider. But dropping individual terminals to H3 removes a very useful visual guide. This is also why I argued for the infobox as a solution to offload the notes section into something a lot more organized.

Regarding linking shared entries: That's something I argued for offloading into the infoboxes as well, especially since these terminals can be easily linked to the shared section.

Well, after an hour or so of good staring at your proposal, CCC, I think you have a very good idea of where to take it. I like your neat and clean organization! I've [[User:Tagaziel/TERMINALS!|used it as basis to create my proposal, expanded with infoboxes and custom level 3 headings to add horizontal lines (visual guideline separating the terminals!). The intention is to replace this with an easily filled-in template that will auto-hide empty field which can be then later filled in at our leisure. I've also included an alternative solution to allow for improving navigation, while allowing to show how the terminal is named in the game.

Simply put, we place [descriptors] in square brackets, so the non-descript terminal becomes [Alan Dalton's] terminal. Tagaziel (talk) 15:00, 20 January 2016 (UTC)

I'm out of this duscussion until sunday evening/monday.
Live peacefully and constructively! \\//_ --CompleCCity (talk) 15:10, 20 January 2016 (UTC)
Back again. No progress except Tagz' merging of our two proposals? No news from Ant?
I understand the search thing… CTRL+F doesn't even work with entries shown!? What the…
I dind't take a whole hour to study the differences. (As in most cases, I could make improvements to my own proposal myself, five days after looking at it the last time, but that's another thing – perfectionism and such…)
Okay, comments…
  • You removed the transcripted header for the standard terminals and Anthony House's, leaving it only in the infoboxes for the personal terminals. Not so with the suspicious ones. Intention? Overseen?
    • By removing that section, even if it is the same for all three types of terminals, you make the raw terminal data with all its headers somehow redundant.
  • It's good to keep the chronological order of the entries intact by listing them in the infobox. (Though you didn't adjust each one, simply copy-pasted the first content into the other ones ;)
  • I don't like your way of removing the in-game names of the terminals from the TOC by calling them "Terminals with shared content" and "Suspicious terminals". It isn't correct either, because the suspicious ones share that content, too. You didn't list them as such.
  • I see the improvement of the descriptors and the horizontal lines, I've thought about the latter myself. Though I don't like the square brackets in the beginning of the header…
  • You didn't solve the cluttering of the suspicious terminals, which I thought had a big potential for improvement.
  • Thanks for keeping minor formattings I integrated that give a better look, like the line break at the transcription start.
I'm sure I haven't listed all I noticed and thought about while looking at your work. But let's see if we can get this even better, I'm working on it again. 'til later, -- CompleCCity (talk) 09:40, 25 January 2016 (UTC)
Okay, new version out now! ;)
I've tried to give the same structure to all main topics. There are now three h2 headings – "Terminal", "Suspicious terminal", and "A. H.'s terminal, besides CC and BTS –, all of which have h3 headings, and for each single entry an h4 heading. I had to "invent" new "chapters" to retrieve this.
I've renamed Tagz' "Shared entries" to "E-mails from the HR dep.". Actually "Access hidden network drive" would be a shared entry, too, though not for all terminals. And A. H.'s terminal doesn't share those entries neither. Thus "Shared entries" is kind of misleading. I think for other terminal entry pages a similar solution is possible, in some cases "Shared entries" would fit well.
Each terminal has its own infobox. Linking here internally to e.g. the e-mail from Jenny DeSoto isn't possible, because there are two of it. Same for Alan Dalton's mails.
I've given up on hiding (> Accessing) the entries because of the non-functional search feature.
I've changed the headings so that they start with "Terminal", the in-game name. The description comes behind, but without the square brackets' idea from Tagz.
I've "merged" the hidden network access so that the "warning" apeears only once. The single suspicious terminals only display the journal entry itself, now.
Some minor changes @ CC – I've moved the template to appear after the heading.
The old version is still hidden on top of the page.
So, what about this? -- CompleCCity (talk) 12:14, 25 January 2016 (UTC)
I love the changes thus far. In fact, I took your version and modified it to streamline a few things, most importantly to make a divider that would clearly identify individual terminals. I went with a dotted line and standardized that across the page. Now, a couple of points regarding the layout:
Grouping terminals under Terminal is redundant, given that the infobox explicitly provides the name of the terminal as displayed in the game. However, pondering that made me realize just what I loved so much about your layout: The grouping of similar terminals under a single heading. I've changed it to Employee access terminals. That still needs to be tweaked, though, to maintain consistency. Right now, to the end-user, the layout can look confusing with some terminals grouped together and another placed under their own top-level heading.
I've also moved the headers to the infobox, which is an even neater solution than including them under the header - and has the benefit of informing the user just what that thing is.
Grouping similar terminals might also help us manage this. Note how the initial deployment had the unique terminal on site neatly placed and then it got surrounded by a complete mess of repeated terminal transcriptions. Ugh. Tagaziel (talk) 16:17, 28 January 2016 (UTC)
Short notes: I like the dotted line more. :) But I didn't understand why you changed the "Terminal" to "Employee…". And I think, removing the transcripted terminal header (the greeting) from the page and putting it un-transcripted into the info box won't find Ant's approval and takes off some nice cosmetic effect. Why are you insisting on this? -- CompleCCity (talk) 17:47, 28 January 2016 (UTC)
Mostly because naming them "Terminal" is redundant, given that we already include the name in the infobox in the proposal. Furthermore, we need to consider the end-user and make sure these top-level headers are as clear as possible. Hey, we both know what it's supposed to mean, but someone coming back to Fallout or who hasn't played Fallout 4 but wants to read the terminals? They're going to be puzzled. We don't want them puzzled.
I don't hold any strong opinions either way, but I moved the header to the infobox for the simple reason that it's clearly identified as such. In the current form, it's fairly unclear what that transcript is supposed to be - and in many cases, it can be confusing to scroll down, hit the header, stop, thinking it's a transcripted terminal option, then resume browsing. Cosmetic effects are cool and all, but consider them long-term: Are they worth it the hundredth time through? :)
Also, your opinion on linking generic terminals? The Fort Hagen terminals page has become a horrid mess after the full generic transcripts, full of repetitions, were added. Tagaziel (talk) 23:41, 28 January 2016 (UTC)

Been busy the last few days what with the storm and all. Will update proposal soon.--Ant2242 (talk) 16:42, 25 January 2016 (UTC)

First the rebuttal

First of all Tags, we do not Edit source materiel. Our terminals pages are source materiel.

Now the mess

Second, the issue at hand is accuracy, it has always been about accuracy. People visiting terminal pages are looking for materiel that they at least believe is there, otherwise they will try the search bar. Your insistence on correcting what Bethesda and/or Obsidian wrote is confounding. It is the complete antithesis of having source content. By accurate presenting the terminals as they are in game give us the ability to also reference the headers and the terminals functions as are both in game and in lore.

Now in regards to these new carve ups of the terminal content; Firstly, why are you insisting on calling the pages "terminals" these are clearly not that. You just spent countless hours editing it so that is specifically is not this. Secondly, why even bother having their own pages at that point why not instead just link directly to the Raw data page, directly from the infobox and save yourself the time and energy? Seriously. It is everything that you want. No, "redundancies," no "difficulty in navigation," and everything is already there in the entire game. So "control + F" is at its best. --Ant2242 (talk) 00:32, 29 January 2016 (UTC)

It's not "materiel", it's "material". And no, what we have on the wiki aren't sources per se. The game and its content are the source and we are providing a synthetic overview that's easy to navigate, browse, and read, so that people don't have to fire up the game and go to the locations to see what items are there. You keep ignoring the fact that we are here providing a service and that service isn't just repeating what's in the game, but editing it so that people can clearly find the material they want and don't have to bother with browsing through repeated content.
Because that's what you made of the Fort Hagen terminals. There was a single unique terminal at the location which was clearly labeled as such. All you had to do was add a list of generic terminals at the top. But no, you had to go and effectively vandalize the page, burying the single relevant terminal in a flood of repeated content. You do realize that you pasted the turret terminal three times on the page and the security door control twice? You made it a mess to navigate and completely useless to anyone visiting the page.
You keep insisting that these must be there. Why? What is accomplished by a text dump that isn't accomplished by a link? Visitors don't want to wade through copious amount of terminal text that repeats itself over and over again just to find the one unique terminal at the location. You are destroying accuracy. There are many contributions of your I love and respect, but this is where you're wrong and causing damage.
To be frank, your attitude is insulting to me, CompleCCity and other users who spent plenty of time extracting and adding the contents of the terminals to the wiki. You are convinced you're the only wise man in a sea of morons. You keep modifying the pages I spent hours creating, modifying them according to your personal policies, because I'm apparently too fucking dumb to do it properly. Tagaziel (talk) 13:36, 29 January 2016 (UTC)


I want to dissociate myself from Tagz' saying, I'd be insulted by you, Ant2242.
And I solicit you, Tagz, to further refrain from such statements regarding my person. I have my own mouth – if I feel offended, I open it.
What really annoys me here, that all this is getting that personal. Isn't this a community? That seeks to present informations, background, and answers about a topic, we all love: Fallout?
So some thoughts/proposals/ideas…
  • I did already ask myself why all those transcriptions are listed on a location related page, rather than linking to the raw data, where all is already existing.
  • What about the idea to split that page into own terminal articles for each EditorID of a terminal, completely with transcripted "Welcome Text", included notes and options, submenues and "Result Text"? Would be round about 500 for Fallout 3 incl. all add-ons. And only those differ from each other (if at all), the placed references don't vary. This would have the side-effect of creating already descriptive names for each terminal, I don't think they would be called "Terminal (EditorID)", but e.g. "Terminal (Jenny DeSoto)".
    • I don't really have an idea, how that would help to restructure the terminal entry pages, but at least we could use links, transclusion, transcriptions. Why not simply linking to each terminal for the location?
  • If there are 10 identical terminals then it should be checked if they refer to different EditorIDs (which makes them possibly not-identical) or if they are all only a reference to the same ID. In the latter case they shouldn't listed all on the page, but instead only once with a note of how many there are.
  • When using links to the original terminal contents (either to the reformatted raw data page or to single terminal articles) instead of transcribing/transcluding/writing down all contents, we could focus on important or individual things. We could list the private e-mails from the H&H TF's employees, the hidden journal entries and A. H.'s terminal on top of the page, making clear from which specific terminal they are taken. And below listing the not-so-interesting-and-repeating stuff.
  • We could use tables/columns to place the important terminals on the page, rearranging them for viewer experience. Creating an infobox-similar box,
    • with an image of the terminal,
    • some infobox content (name, lock, …),
    • a formatted (transcripted) welcome text, that clearly is recognizable as this, not irritating the viewer,
    • a chronological listing of all contents, but only linking general entries (like the HR e-mails),
    • thus presenting an easy to understand information, focussing on important things.
    • In addition, as link or on the bottom of the page, all transcriptions can/should remain – for the sake of completeliness (this word doesn't exist, does it? ;), source materiel, transcriptions and all that sort of stuff.
@ Ant2242: I think I understand what you're trying to do with your layout of the terminal entry pages, and for many things I think the same way (I think). (So many thoughts, here… ;) But don't you see the chaos, the difficulties of differentiating important and not so important things for the viewer, all those things that Tagz is trying to implement? I think, you see…
@ Tagz: Your thoughts of viewer friendliness, ease of use, and all that, are important, are appropriate, are right. But not via editing the sources out, the formats, the names… not via rewriting the game.
As Garroux wrote here some time ago, we should find a compromise, staying faithful to the game, the sources, the Bethesda input, but at the same time making it easy to find information, making it a good experience of surfing through the articles. And I'm not speaking of the passing by reader, we ourselves as contributors, as architects, would enjoy a proper layout.
I don't know how much more time I will invest into this topic. It was a bit difficult for me as non-native speaker to write all this down. I hope I am saying what I wanted to.
So long as repeated reverts continue and you both don't find a more constructive way to debate all this I'm not feeling very motivated to spend more energy into this. There are other things to do, I'm much into the locations for now, as a preparation for giving as exact locations as possible on the container articles.
-- CompleCCity (talk) 17:08, 29 January 2016 (UTC)

It's mostly my frustration with Ant's insistence on cluttering up pages with contents that can easily be linked to, as they are repeated. Like the mess he created on the Fort Hagen terminals page, which is absolutely horrid. It's what prompted my post, as seeing that really, really hurt. For reference: I spent a good several hours working with the output of all the terminals in Fallout 4, creating an easy to use layout that allows me to easily place the terminals' content on the wiki. And then Ant comes in, decides I'm too stupid to do it properly, and forces his personal policy through sheer stubborness, regardless of the end result.

The idea of this forum was to create a common standard that's easy to navigate, understand, and does not contain repeated information. That's why I campaign for:

  • Naming the terminals as precisely as possible for the sake of navigation. That way we can easily link terminals, find relevant items, and nothing's lost in the process. We already differentiate between the different laser rifles available in the game by their lore name, using Wattz 2000 laser rifle in lieu of laser rifle (Fallout) or Winchester P94 plasma rifle instead of plasma rifle (Fallout). It's an established convention that adds to the wiki's user-friendliness.
    • On that note, noting that the terminal's in-game name is Terminal is kind of pointless. Some 90% of terminals have that name.
  • Yes, yes, and yes on simply linking to generic terminals. As seen on Fort Hagen terminal, transcripting every single terminal's contents leads to obscuring the relevant ones. I have the Terminal output available (please message me at my e-mail address, I'll share you in) and in Fallout 4 the generic terminals are literally generic terminals. They are a distinct group, with a different prefix from terminals unique to locations.
  • Dividing terminals by location is, in my opinion, the simplest way of going about it, as it's intuitive and close to the actual terminal structure in the game's files (which are typically prefixed with the cell ID), as well as allows for easy searching by groups. Imagine searching an entire category of individual Prydwen terminals...
  • The one accusation I don't understand is that I'm trying to rewrite the game. I'm not. Any edits are there to improve clarity and ease of navigation, basing on established convention and precedent (see above for the item example), and I don't touch the actual contents of the terminals.

I think there are three issues that need resolving:

  1. Dealing with generic terminals (terminals that have the same content regardless of their placement). I propose simply linking them, rather than transcribing them in their entirety, to improve navigation. They are still listed on the page.
  2. Dealing with repeated content (terminals where entries repeat several times, such as the HR e-mails). I propose to transcribe them once and then link to them from each individual terminal. Perhaps through an infobox?
  3. Naming terminals for navigational purposes. Given that 90% of terminals, if not more, are named Terminal, adopting a descriptive naming convention sacrifices little of value (since the headings are not part of the transcription, but part of the navigation). Most of the terminals have a very descriptive editor ID, which can be used to differentiate them. It's the convention I used for all Fallout 4 terminals.

To be frank, I'd like to work with you, CCC, and develop a common standard. You have plenty of really good ideas. Tagaziel (talk) 18:36, 29 January 2016 (UTC)

Pt1
"Tomato, Potato, Tato". The terminals - specifically written by the developers - as presented in game are source texts.
That's nonsense. Again I ask why then not just link directly to the Raw data page and be done with it? You get everything you want.
Please let me make this abundantly clear, If you or anyone else takes my tone as insulting I apologize, this is not my intent. I must insist however that I have certainly spent plenty of my time ensuring accuracy of every single one of those articles. (Barring the terminals for which there is no Raw data page.) I keep formatting (and yes sometimes correcting) pages that you spent hours creating.
Pt2
I have not been insulted by you, please let me apologize if I have insulted you or come off as some sort of brute.
Yes we are, and after - at least - three years of formatting, correcting, and ensuring the accurateness of every single header, entry, and closer I could, now out of no where we are arguing about editing source documents format.
So some thoughts/proposals/ideas…
  • I did already ask myself why all those transcriptions are listed on a location related page, rather than linking to the raw data, where all is already existing.
  • What about the idea to split that page into own terminal articles for each EditorID of a terminal, completely with transcripted "Welcome Text", included notes and options, submenues and "Result Text"? Would be round about 500 for Fallout 3 incl. all add-ons. And only those differ from each other (if at all), the placed references don't vary. This would have the side-effect of creating already descriptive names for each terminal, I don't think they would be called "Terminal (EditorID)", but e.g. "Terminal (Jenny DeSoto)".

Although I am not against this, wouldn't the current locations overview provide all of this, plus the added benefit of descriptions within the location and specific details of the entries/commands without cluttering up the layout page?

    • I don't really have an idea, how that would help to restructure the terminal entry pages, but at least we could use links, transclusion, transcriptions. Why not simply linking to each terminal for the location?
  • If there are 10 identical terminals then it should be checked if they refer to different EditorIDs (which makes them possibly not-identical) or if they are all only a reference to the same ID. In the latter case they shouldn't listed all on the page, but instead only once with a note of how many there are.
— CompileCCity
If the terminals are identical in both name and content (command or entry) then I grouped them together, opting for a detailed, localized "note:" section.
  • When using links to the original terminal contents (either to the reformatted raw data page or to single terminal articles) instead of transcribing/transcluding/writing down all contents, we could focus on important or individual things. We could list the private e-mails from the H&H TF's employees, the hidden journal entries and A. H.'s terminal on top of the page, making clear from which specific terminal they are taken. And below listing the not-so-interesting-and-repeating stuff.
— CompileCCity
Why not just link directly to the specific entry within the terminal from the Infoboxes using a colbox template?
  • We could use tables/columns to place the important terminals on the page, rearranging them for viewer experience. Creating an infobox-similar box,
    • with an image of the terminal,
    • some infobox content (name, lock, …),
    • a formatted (transcripted) welcome text, that clearly is recognizable as this, not irritating the viewer,
    • a chronological listing of all contents, but only linking general entries (like the HR e-mails),
    • thus presenting an easy to understand information, focussing on important things.
    • In addition, as link or on the bottom of the page, all transcriptions can/should remain – for the sake of completeliness (this word doesn't exist, does it? ;), source materiel, transcriptions and all that sort of stuff.
Although I am not against this table format per say, using the wiki's search function with this format is impossible - please see every Gamebyo dialogue file <:-( . Furthermore every terminal with generic entries must have their generic entries, to do otherwise is to manipulate the source Tato material.
@ Ant2242: I think I understand what you're trying to do with your layout of the terminal entry pages, and for many things I think the same way (I think). (So many thoughts, here… ;) But don't you see the chaos, the difficulties of differentiating important and not so important things for the viewer, all those things that Tagz is trying to implement? I think, you see…
@ Tagz: Your thoughts of viewer friendliness, ease of use, and all that, are important, are appropriate, are right. But not via editing the sources out, the formats, the names… not via rewriting the game.
As Garroux wrote here some time ago, we should find a compromise, staying faithful to the game, the sources, the Bethesda input, but at the same time making it easy to find information, making it a good experience of surfing through the articles. And I'm not speaking of the passing by reader, we ourselves as contributors, as architects, would enjoy a proper layout.
I don't know how much more time I will invest into this topic. It was a bit difficult for me as non-native speaker to write all this down. I hope I am saying what I wanted to.
So long as repeated reverts continue and you both don't find a more constructive way to debate all this I'm not feeling very motivated to spend more energy into this. There are other things to do, I'm much into the locations for now, as a preparation for giving as exact locations as possible on the container articles.
— CompileCCity
Yes, but we "shouldn't... couldn't... sh'couldn't" edit the source materiel. The source materiel in the terminal entries pages isn't just the content, commands, or headers/closers, its also how the terminal itself is presented in game. From every misspelling, to every grammatical error, to the layout and scripting errors of each terminal must be noted.
I've been trying to find some sort of compromise, some sort of "ease of use and presentation" however beyond some sort of model viewer (one that contains all a terminal is and allows the search function to operate) our current locations overview seems to be the best bet.
Your English is fine, and I cannot agree more, there is Aplenty to do already (you should see my personal pages... and the notepad... and those ~10 pages of notes that I have yet to add to the notepad).


For better (ie Prydwen's terminals) or worse this is how Bethesda designed the terminals of that location. I know how you feel, it is not pleasing to the eye, however that is the content that they have chosen. I am sorry that you feel that way, I assume it's the same way that I feel about your changing of the source text format. I know too the pain of pouring hours and hours of tedious work to ensure accuracy and I too feel the way that you do. As if you came in, and decided I'm too stupid to do it properly. Literally carving up years of work.

  • Naming the terminals as precisely as possible for the sake of navigation. That way we can easily link terminals, find relevant items, and nothing's lost in the process. We already differentiate between the different laser rifles available in the game by their lore name, using Wattz 2000 laser rifle in lieu of laser rifle (Fallout) or Winchester P94 plasma rifle instead of plasma rifle (Fallout). It's an established convention that adds to the wiki's user-friendliness.
— Tags
We differentiate on the overview, not the page name. This is a little different as the overview contains the page game. Perhaps "Terminal (description of some sort)", while maintaining the reference presentation format guidelines?
  • Yes, yes, and yes on simply linking to generic terminals. As seen on Fort Hagen terminal, transcripting every single terminal's contents leads to obscuring the relevant ones. I have the Terminal output available (please message me at my e-mail address, I'll share you in) and in Fallout 4 the generic terminals are literally generic terminals. They are a distinct group, with a different prefix from terminals unique to locations.
— Tags
Not all terminals that use generic commands are generic terminals, some have unique content or contain multiple commands, which is why I opted for the translusions rather than just linking the terminal content(s) wholesale.
  • Dividing terminals by location is, in my opinion, the simplest way of going about it, as it's intuitive and close to the actual terminal structure in the game's files (which are typically prefixed with the cell ID), as well as allows for easy searching by groups. Imagine searching an entire category of individual Prydwen terminals...
  • The one accusation I don't understand is that I'm trying to rewrite the game. I'm not. Any edits are there to improve clarity and ease of navigation, basing on established convention and precedent (see above for the item example), and I don't touch the actual contents of the terminals.
— Tags
Exactly why the wiki is using this format to begin with. Because by editing the terminal names and command/entry header-activators (whatever the actual name is) we are editing he source materiel. Furthermore the source materiel in the terminal entries pages isn't just the content, commands, or headers/closers, its also how the terminal itself is presented in game. From every misspelling, to every grammatical error, to the layout and scripting errors of each terminal must be noted.
  1. Dealing with generic terminals (terminals that have the same content regardless of their placement). I propose simply linking them, rather than transcribing them in their entirety, to improve navigation. They are still listed on the page.
  2. Naming terminals for navigational purposes. Given that 90% of terminals, if not more, are named Terminal, adopting a descriptive naming convention sacrifices little of value (since the headings are not part of the transcription, but part of the navigation). Most of the terminals have a very descriptive editor ID, which can be used to differentiate them. It's the convention I used for all Fallout 4 terminals.
— tags
1. Not all terminals that use generic commands are generic terminals, some have unique content or contain multiple commands, which is why I opted for the translusions rather than just linking the terminal content(s) wholesale.
3. Doing so would call into question the actually named terminals, which again is also part of the content. Perhaps "Terminal (description of some sort)", while maintaining the reference presentation format guidelines?
Interesting, I've been using the Raw data pages, which are that but for the text (mostly) entries/notes. If we are to include these terminal IDs shoudn't we also include the Editor & Base IDs of the individual entries/notes as well?

--Ant2242 (talk) 04:32, 2 February 2016 (UTC)

What's on the wiki is not the source material. It can never be source material. The only source material is the game. What is on the wiki is an edited, local copy that's present for ease of use, searching, and SEO. It is modified not to reflect how it looks in the game (because, as you note, that is impossible), but to provide a version of the material that contains the relevant contents and can be easily searched, copied, and referenced.
This is why we have never tried to emulate the terminals as they look in Fallout or Fallout 2, but simply used the underlying MSG files. That's established practice and what I'm arguing for.
Generic terminals are generic terminals. I've sent you a copy of the extracted terminals (both the raw dump and the organized version, with formatting marks applied) and hopefully that'll convince you that linking is sufficient. I mean, my entire work on terminals is based on that output and the entire structure of the Fallout 4 terminals pages follows from that: Transcribing terminals with contents specific to the location (as per established practice). Generic terminals can be linked to. I mean, Fort Hagen terminals is a mess. Security door controls are repeated three times, turret control four, both of which share the exact same contents. Finding the only location-specific terminal is exceedingly difficult.
Naming terminals doesn't call into question named terminals. It's a non-issue. What is lost by using descriptive names based on the terminals' editor IDs?
And point is, your edits to Fallout 4 terminals have shown (again, Fort Hagen terminals) that trying to show everything exactly as it appears in the game is a poor, poor approach. Linking generic terminals doesn't remove content (as the user is still able to find what terminals happen to be included), while greatly enhancing navigation. Compare and contrast. Tagaziel (talk) 12:31, 2 February 2016 (UTC)


As a short and not directly to the new arguments related comment I here repeat my answer to Tagaziel, found at his talk page:

Re: The Terminals

Hi.

Yes, I had some ideas, although very vague until now. They are growing, new ones join, some leave, some loose their head, … :)

I didn't answer (until now) because those ideas aren't tangible enough, and because I wanted to wait for some sign of life (despite his changes) by Ant2242. In addition I don't really know what I would do with those FO4 terminal entries you wanted to e-mail me.

  • @ the "box": I don't believe that that idea would look very good. But perhaps I'll find a way…
  • Completely new approach: Expanding location articles with a new paragraph "Terminals", which could summarize important entries to be found at that location. With the use of {{Main}} the original pages could even be left untouched – and Ant would be pleased.
    • But this would be hard to implement without cluttering the loc pages. And sort of a revolutionary change to well established guidelines. ;)

I think I will create some examples sooner or later; sorry, if that confuses your time plan. The location thing is more complex than I thought, let's see when I will need a break and like to do some more creative stuff. Btw., I'd like to have a feedback on my first disambig creation, Silo. -- CompleCCity (talk) 18:53, 1 February 2016 (UTC)

— CompleCCity
By the way, my name is CompleCCity, not CompileCCity! ;) (Indeed it would be compleCCity, with a small "c" at the start, but in times when I first registered my account on wikia (which later was transferred to here) they didn't allow lowercases at the start of a username, changed it automatically to an upper case "C".) And it's okay to call me cCC (or CCC, like Tagz already does), which is the same I am adding as prefix to my own mods and editor IDs. :)
Perhaps today is the time for me to tinker with this again… But first I'll complete the DLC05 interiors for FO3. -- CompleCCity (talk) 13:08, 2 February 2016 (UTC)
I've done some things, but those are only first steps. If somebody's interested… -- CompleCCity (talk) 20:27, 2 February 2016 (UTC)
What's on the wiki is not the source material. It can never be source material. The only source material is the game. What is on the wiki is an edited, local copy that's present for ease of use, searching, and SEO. It is modified not to reflect how it looks in the game (because, as you note, that is impossible), but to provide a version of the material that contains the relevant contents and can be easily searched, copied, and referenced.
— Tags
No, what is on the wiki is the archived source material. As it is the game files or images of the game itself. Modification is frowned upon, because we are not the ones to edit source materiel. This is why page format is so important. We must keep all material as close to the game as humanly possible. As for the "impossible" I am specifically referring to using the wiki's search function regarding the tables. When content is in tables it does not get searched by the function, only the page name is counted.
This is why we have never tried to emulate the terminals as they look in Fallout or Fallout 2, but simply used the underlying MSG files. That's established practice and what I'm arguing for.
— Tags
That is completely different, the msg files are for entire computers. If you really wanted to emulate the Fallout 3, NV, & 4 terminals like the ones in 1 & 2 then you would have to add each separate transcripted entry by Editor ID to the wiki, then link them all individually.
Generic terminals are generic terminals. I've sent you a copy of the extracted terminals (both the raw dump and the organized version, with formatting marks applied) and hopefully that'll convince you that linking is sufficient. I mean, my entire work on terminals is based on that output and the entire structure of the Fallout 4 terminals pages follows from that: Transcribing terminals with contents specific to the location (as per established practice). Generic terminals can be linked to. I mean, Fort Hagen terminals is a mess. Security door controls are repeated three times, turret control four, both of which share the exact same contents. Finding the only location-specific terminal is exceedingly difficult.
— Tags
Generic terminals are generic terminals, however some use multiple commands and other different headers. Sometimes even unique terminals have a generic command or two. Which makes them different to the other terminals of the location in question. My experience with the terminals in all three games shows this. Compare and contrast
Naming terminals doesn't call into question named terminals. It's a non-issue. What is lost by using descriptive names based on the terminals' editor IDs?
— Tags
Yes it does, how can someone be sure of a terminal name or even the entire rest of the article if portions of it are tastefully edited? This is why I opted to separate the "Note:" section from the game content.

--Ant2242 (talk) 22:39, 2 February 2016 (UTC)

Re
Terminals
Why not just link them within the Infobox and layout while describe them in the layout?
My bad CCC.
I love the edited raw game data page, the information added can be traced back to the individual terminal allowing ease of verification. Please continue so that I may finish those terminals. ...maybe a description of what is there? Such as what is the header, what is the entry/command link and loading notice at the top of the page. For example '...this page contains terminal headers, closers and command links. The | separates the entry/command link while the --- separates the header from its links and closers.'
This format is something we all should look more into, what about section entry/command notes? Such as accessing an entry and getting a holotape, or explaining what the command does? Could we get the search function to all a search of its contents?

--Ant2242 (talk) 22:39, 2 February 2016 (UTC)

Logical extreme[edit source]

Ant, the archived local copy is not source material. This is something you keep ignoring in favor of making up a rule that we must be as close to the game as possible. Where is that rule? Because the applicable rules are The Vault:REF and VA:C, neither of which stipulate that what is on the wiki is source content or that what is archived on the wiki should be as close to the game as possible.
That means the Fort Hagen terminals page will go. It is not encyclopedic and violates our own policies and guidelines, including brevity (the page is anything but) and information. Dumping entire terminals' worth of text on the page, repeating identical contents several times over, is not useful to anyone but yourself. Two separate users have already told you that Fort Hagen terminals is broken beyond use. How many have to say the same for you to understand that you're hurting The Vault's usability as a source? Same by your insistence on using the general "Terminal" name to destroy navigation on the page. I remind you that the navigation names are emphatically not transcripted.
That said, I think cCC has the right idea: Your idea about terminals belongs more in the individual location's layout section, rather than the terminals page. Terminals pages should only be used for the terminals' contents, rather than placement.
So, another proposal:
  1. All notes present on the terminals pages are to be removed and integrated in layout articles.
  2. Terminals pages, as per their titles, are to be used for location-specific terminals and their contents, as identified by ID. Generic entries can (but don't have to be) listed under a separate heading at the bottom of the page.
  3. The raw page can be converted into a master list of all terminals, with their trees preserved.
  4. The terminals pages take precedence over the raw page in linking, due to their increased usability and readability. A link to the master list can be retained via a notice at the top.
As an addendum, Ant this is a proper archive of the source material. Anything you remove from that file results in an edited version of the source, rendering it a modification of source material you seemingly abhor. You are not recreating the source when you describe what's in the game. You're only creating a description, your own impression of how it looks. So tell me, why are you editing source material? How can anyone rely on what you write when you remove such crucial elements as baseID and refID, or the texture hash? Not to mention the hexadecimal format of compiled script used by a given terminal or, in fact, the scripts used by the game... So, in order to "keep all material as close to the game as humanly possible", every single byte in that file has to be present on the wiki. With no modifications, of course, as we can't modify source material. That includes wiki links or breaking that file down into smaller, readable chunks. Tagaziel (talk) 11:03, 3 February 2016 (UTC)


Though I'm at the moment dealing with another thing I have to ask and say something.
@ Tagz: I can't understand why you moved the raw FO3 terminals to raw FO3 notes, removing all former content of that page. Where are the notes now?
Additionally I like to know, where you did get this file, this "source material" from. This is a copy-paste action from FO3edit, am I right? I doubt that copy-pasted data from a non Bethesda tool would count as source material.
I don't understand why splitting different entries by adding some additional information (base ID, editor ID, …), but leaving the content itself – which was extracted from a text file, exported directly from G.E.C.K. (source material in my understanding) – untouched, transcripted, should be "editing of source material". Again: Where are the source notes now?
Until now I didn't really understand the purpose of these pages, but it appears to me as they are what they are: a source. Something contributors can look into and getting information out of it to transclude this into normal articles. I by now don't think it's a good idea to link to those pages from every terminal or note article because they should be mostly untouched.
Also it seems as you misapprehended me: My idea was to put notable terminal entries to the location page and leaving the terminal pages as they are, not viceversa. Or am I now getting something wrong? -- CompleCCity (talk) 12:57, 3 February 2016 (UTC)

My bad, the Notes are all here. This is the entire record section of Fallout3.esm decoded into human-legible material, containing every bit of data accessible through the GECK. This is what Ant wants, to do everything as is in the game. And this is the underlying material, every bit of data that gets us as "humanly close as possible" to how it looks in the game, within the limitations of the wiki software.

The purpose of raw data pages was always to contain raw data dumps, it's even there on the page:

They are supposed to provide a way to look up data normally only available through editing tools (such as the G.E.C.K.) for editors who are unable to use these tools.

Until now, they were broken, edited versions of the source material by definition used by Ant. The purpose of this exercise is to demonstrate that he is, in fact, editing source material, by picking and choosing what he deems important and ignoring what he feels isn't. Right now the source dumps are complete and have everything, also demonstrating the utter pointlessness of trying to convey everything the game has.

I don't think putting notable terminals on the location page is a good idea. We already have separate articles for terminals, which were intended to contain just the text from terminals at a given location. No more, no less. They weren't supposed to list every bit of information regarding to terminals, or repeat the same content seven times over in a misguided attempt to recreate the game. The point was to allow for quickly searching through terminals at a given location, through content unique to that location. That's it. They were supposed to be a simple text reference for contents.

Which is why I'm pointing out that any layout notes should go into the location terminals, data can be offloaded into a single master article listing every terminal and its configuration, and the text contents kept as they are: In X terminals articles, kept legible by dividing them into unique (transcripted) and non-unique (linked) contents. Tagaziel (talk) 15:09, 3 February 2016 (UTC)

While formatting changes to these pages are acceptable, the actual data should remain untouched.

If this is how you wish to revamp the Raw data pages, fine. You however have failed to prove that I am the one editing source materiel. As again I am transcribing what is in game as it appears. Literally a transcript for everything presented on the terminals of each specified location. You are the one pushing for renaming the terminals while removing some content.
PS I will be restarting the FO3 terminals review (I hope, sooner rather than later) with this (as you say) finished Raw data page. Please continue with the rest of the pages.
The terminals pages are to present the terminal locations, functions, content, and other miscellaneous materiel (such as cut content and page/content notes) in context by location. As this is the best way to account for said terminals. Otherwise, again, why not just call all the terminals pages "terminal entries" and leave all context off the page.
Once again the terminal name, and command/headers are also part of the transcript. They are completely in context and referenced appropriately.
--Ant2242 (talk) 05:10, 6 February 2016 (UTC)
"The terminals pages are to present the terminal locations, functions, content, and other miscellaneous materiel (such as cut content and page/content notes) in context by location. As this is the best way to account for said terminals. Otherwise, again, why not just call all the terminals pages "terminal entries" and leave all context off the page."
On what basis do you claim that? This was not discussed at all, it's what you push for without having any basis in existing policies or guidelines. Feel free to propose, but this was not accepted by anyone and leads to messes. Tagaziel (talk) 15:58, 6 February 2016 (UTC)
This is what the pages are since their inception. Like it or not all I have done is standardize and verify.--Ant2242 (talk) 20:34, 6 February 2016 (UTC)
No, they are not. Since their inception, the purpose was only to get the text in a single location. Where'd you get the idea that they were supposed to be something else? Tagaziel (talk)
Yes. yes they are. As since the very beginning they were to record the text of the location. Again all I did was standardize, verify and link appropriately.--Ant2242 (talk) 00:01, 7 February 2016 (UTC)

And where did you get the idea that they were supposed to be a mess of repeated text that's impossible to navigate? If you want that mess, fine, make a subpage of the terminals page, but do not force users to wade through a hundred repetitions to find the lone terminal they're interested in. Tagaziel (talk) 19:08, 8 February 2016 (UTC)

It is exactly as navigable as is in game. Why even bother to create that "sub page" when you could just link directly to the Raw data page. Or perhaps you could create your "brevity pages" with just the single entries. No context or order.--Ant2242 (talk) 21:05, 9 February 2016 (UTC)
Fort Hagen terminals celarly shows that the approach you try to force is what lacks context or order. Sorry Ant, but you're simply wrong on this. Tagaziel (talk) 14:04, 10 February 2016 (UTC)
Yet again you have carved up the page. Removing the context and order of the terminals. Sorry Tags, but again you're simply incorrect. (If you haven't noticed some terminals have more than one command, and there is far more than one terminal at the location.)
PS still waiting for the other Raw pages. (Maybe you don't like the new format you introduced there, whatever the case is. It also needs completion and standardization.)--Ant2242 (talk) 23:39, 10 February 2016 (UTC)

There is no carving up. Everything's there and there's absolutely no value in pointing out that a terminal has more than one command. What you mention is fit for the layout section of each individual location (given that which terminals control what is relevant to the location's gameplay, not their terminal contents). Also, please point out the policy or guideline mandating that this mess is "context" and "order". Tagaziel (talk) 15:13, 11 February 2016 (UTC)

To fish or cut… down[edit source]

There are two reasons I've been rather inactive here:
First, the new format of the raw data pages, and
second, the ongoing, fruitless dispute between Ant2242 and Tagaziel.
The first thing makes me feel irritated and the second listless.
One says "yes", the other "no", one says "A", the other "B" – never a "maybe", never an "AB".
So I've decided to cut all this down to some questions that in my opinion need to be answered if we want to come to a conclusion.

1. Shall the raw game data look like[edit source]

  1. the version recently submitted by Tagz for the FO3 notes, the most complete option, kind of an image of the game data?
    +   as complete as possible
    -   um… useless?
  2. the former version, still be found at the FNV notes, copied directly from a G.E.C.K. export and thus indeed "raw" data, structured by IDs?
    +   clean of redundant information; linkable, quotable, searchable; structured
    -   still a wall of text; errors may occur while structuring or through multiple copy-paste-actions
CompleCCity: I prefer the latter version; it serves the purpose and one can work with it, not so with the "image". Once completely structured, ID'd, and linked, I propose a (semi-)protection of those pages.

2. Shall certain terminals[edit source]

  1. furthermore be contained in an overview page, together with all other terminals for the related location?
    +   easy navigation between related terminals; no additional work
    -   one has to know the location to find a specific named terminal; clutter, hard to find certain entries, lots of scrolling; even more clutter and scrolling for certain locations
  2. get their own article?
    +   individually named terminals can be searched for; focussed content; more layout options
    -   more work, more articles; layout has to be defined (guideline); related terminals are not combined
  3. still be listed amongst related on a location overview page, with individual, specifically named, or otherwise important terminals getting their own article?
    +   look above and sum up
    -   look above and sum up
CompleCCity: I prefer the third option. I would make the overview a "main article", the individual pages can transclude the content from the overview. (There may be problems with formatting, I don't think that the {{Transcluded}} can work together with {{Transcript}} or <pre>.) The terminal links on the location page should call the individual pages, which then contain the {{Main}} hint.
CompleCCity: I propose to expand the layout section of many location pages by their respective sections, the local cells with an individual name on the Pip-Boy map or at least an own cell name. For some locations that is done, but for many there's only one layout paragraph, summarizing all integrated sections. With this done – or perhaps already before – the LOCATION terminals pages should reflect the sectioning of the location. A really small example, but one I've noticed: the Grayditch terminal entries, though only two, should be separated into Brandice's house terminal and Recently built shack terminal – to stay with the location naming. This doesn't make lots of sense for exactly this example, but other LOCATION terminals pages would benefit from it (not all, though): Less clutter, less repetitions.

3. Shall repeated content of one location's terminals (like the Welcome Screen or mass mailings)[edit source]

  1. appear for each terminal with this entry on the overview page?
    +   propriety, integrity, chronology; in game feeling
    -   clutter, hard to find certain entries, lots of scrolling
  2. be separated from individual entries, perhaps put on top of the page or being otherwise hinted at?
    +   less clutter, no repetitions while reading; focus on individual entries
    -   chronology difficult to present; reservations regarding integrity
CompleCCity: I prefer the latter. Integrity is given in my eyes when all entries are presented somehow, and their chronology is preserved. Though there may be better ways, but examples how to do this were given.

4. Shall the terminals look[edit source]

  1. like the best possible way in emulating the game, while parallel illustrating the quotation state of the entries?
    +   unique layout; in game feeling; clarity, that content wasn't written by a contributor but is directly from the game
    -   unique layout; hard to transclude layout; can appear strange to certain readers; more cluttered
  2. like every other standard page in the wiki, with several sections and default formatting?
    +   no distraction by layout; easy integration into other pages (e.g. {{Transcluded}}, {{Main}})
    -   loss of quotation character; prone to unqualified edits
CompleCCity: I don't have a fixed opinion about this. I like the current feeling of the font, the layout; makes it clear, "that is a terminal". But I understand the formatting limitations it brings with it. And that icon, the pen 'n' paper doesn't really suit an electronical note.


So far these are the main questions coming to my mind by now.
Feel free to add more questions, more advantages and disadvantages, your own comments. (Please try to maintain the given formatting, and "sign" adds with your username.)
If you want to discuss certain aspects, please don't do this within the questions, add a new section instead.

I'd say we leave this some time for consideration and addings. After that someone with the appropriate knowledge could make some poll out of it.

So, what do you think? -- CompleCCity (talk) 13:36, 13 February 2016 (UTC)

Promotional Content