Update _child_google_create_account.Rmd

[KatherineCox]

With the changes in policy preventing non-institutional Google accounts from accessing Controlled-Access Data, I thought it would be useful to include a warning. I also did a little reorganizing.

Todo:

• point back to main before merging
• consistent email vs. e-mail

[github-actions]

No broken url errors! 🎉
Comment updated at 2025-05-28-12:48:03 with changes from 2dad8cf

[github-actions]

No spelling errors! 🎉
Comment updated at 2025-05-28-12:48:01 with changes from 2dad8cf

[github-actions]

Re-rendered previews from the latest commit:

• 👀 Quick preview of course website here *
• 🔬 Comprehensive download of the course website here

* note not all html features will be properly displayed in the "quick preview" but it will give you a rough idea.

Updated at 2025-06-20 with changes from the latest commit 6fa9ab9

[avahoffman]

Thanks for adding this!

I wonder if the way this is organized currently requires the user to read a lot before making a decision.

Maybe we could do something like:

**Choose Your Account Type**

-> Do you plan to work with controlled-access data (GTEx, dbGaP)?
IF YES, you MUST use an institutional email address (see option 1)

-> Will you be moving between institutions?
IF YES, you might consider a gmail account (see option 3)

**Detailed Instructions**
[content you already have here]

I see Non-Google Institutional Account and Institutional Google Account as the same thing from Terra's side, it just requires more user set up. So maybe simplifying to something like

1. **Institutional Account**: If your institution uses G Suite, you can sign into Terra directly using your institutional Google account. If your institution does not use G Suite, you can create a Google account that is associated with your non-Google institutional email address by following [these instructions](https://support.terra.bio/hc/en-us/articles/360029186611).
1. **Unaffiliated Google Account**: You can access Terra with any Google account. If you have an existing Google account (such as gmail.com), you can use it to sign into Terra. If you do not already have a Google account that you would like to use for accessing Terra, [create one now](https://accounts.google.com/SignUp).

Also, I think we might want to avoid h-level headers in child docs since they can be incorporated at different levels in the main document.

[KatherineCox]

@avahoffman Thanks for the review! Working on incorporating your suggestions.

Also, I think we might want to avoid h-level headers in child docs since they can be incorporated at different levels in the main document.

Do you think this is a problem if they're unnumbered? (I mean, from a technical and accessibility standpoint it's not great, it clutters up the document outline and mixes style and semantics. Just wasn't sure it was worth putting effort into improving.)

• Easy fix: no title. I liked having the title because it lets people quickly decide whether the warning box is relevant to them.
• Easy fix: use bold text instead of headers. I felt like this didn't stand out enough to call attention, but maybe it's fine (see screenshot below).
• Harder fix: new css class. The technically correct thing to do would be to make a new css class for callout box titles. Wasn't sure if this was worth the effort / additional complication, but it would let us accomplish the same styling without using headers.

This may become moot for this particular PR, I haven't yet played around with your suggestion about "Choose Your Account Type". But regardless, it seems like something we might want more generally, to be able to include titles in callout boxes.

Thoughts?

[avahoffman]

Do you think this is a problem if they're unnumbered? (I mean, from a technical and accessibility standpoint it's not great, it clutters up the document outline and mixes style and semantics. Just wasn't sure it was worth putting effort into improving.)

I think any header is ok if they're inside a callout box.. Do they all get treated as the box "title" ?

I'm not as much concerned about numbering but about pagination/organization and flexibility. Philosophically, I was thinking that the writer of the books determines all the H-level headers (since they may or may not go all the way down to H4). That way, they could be in control of page breaks at the H1 level. So a user could determine which of the following they want to do:

# header
## subheader
### subsubheader
<borrowed chunk>

OR

# header
## subheader
<borrowed chunk>

This isn't a hill I want to die on though, so happy to do whatever is easiest to maintain.

[github-actions]

OTTR Check Results

Summary

• Spelling check: ✅ PASSED (0 errors found, threshold: 0)
• URL check: ✅ PASSED (0 errors found, threshold: 0)

🎉 All checks passed!

Last Updated: 2025-06-20-13:54:16