Change:
I have created this issue so we can come to a final conclusion about the best format of notes when they are to the or sections of a challenge file. Below are all the combinations I have seen scattered throughout the curriculum. There may be others, so please let me know and I will update the list. This only applies if there is a single note. For multiple notes (which in my opinion starts to get unnecessary), see later in this topic. Example 1: Example 2: Example 3: Example 4: Example 5: Example 6: Example 7: Regarding situations where two or more separate notes are , I have seen: Example 1: Example 2: Example 3: If everyone can cast a vote for their preference of both a single note and multiple notes, this will help us in deciding on one way and then we can update the Styling Guide for challenges in the documentation.
I will cast my vote as I prefer Example 7 for single notes, because it takes up less space and adds one additional space between the word and the content. I like Example 3 for multiple notes, because I like the to be bold.
I'll vote for number 6 for the single notes and number 3 for multiple notes. I don't really see the need for extra space between and whatever comes after it, a simple space is fine
Also to add on, perhaps we can have a background-color for all Note sections as we want users to pay attention to those sections particularly. Something like this: ! Color code used: #C9F8CF
This is the style guide contain freeCodeCamp's Brand colors: https://design-style- . We try to deviate as least as possible from this and I'm yet to see a major deviation
Also, the note is not the most important thing in the challenge. The actual instruction is. We don't want to highlight anything that is not relative to the instruction. Most of the time, these notes are FYIs.
I vote for example 6 and example 3, The says to use something in none of the examples for single notes, the output would be the same as example 2, I think - Also, the guide doesn't say anything about multi-notes
6 and 3.
I vote for example 6 in single notes and example 3 in multiple notes.
I think it is settled then. 6 and 3. What do you think?
Agreed, with you all. Thanks. Please proceed with pull requests.
I would like to work on this. Is there a way to assign my name under the assignee? I am not able to do so
Hi Go ahead with PR. We cannot assign you the issue. It's unfortunately a limitation from GitHub. Feel free to make a PR. We usually allow the first open and valid PR to go in as a fix. Thanks.
The suggestion in the PR above says to make a multi-note different from the example - so I did some testing to see the outputs and thought I should share.<brthese codes.... <img width="570" alt="screen shot 2019-03-05 at 10 26 56 am" src="https://user-"produce the following...<br<img width="415" alt="screen shot 2019-03-05 at 10 27 51 am" src="https://user-"The first two here produce the same result (same as example 3 above)... I'm not sure I like that extra space in there - I suppose it's fine, but I made a few others to see if I could make it look more like how I think it should look. So basically, I'm saying, I'm having second thoughts on how we should do the multi-notes.
I found more cases for single note. Perhaps you can update the list Case 1: Case 2: Case 3: Case 4:
Are you going ahead with a PR to put it somewhere into the docs?
Are you converting them to the suggested style And have you come across many multi-notes?
In challenges like , we have this sentence: Note that property names with spaces in them must be in quotes (single or double). So, should that sentence also be converted to: or can we ignore such cases?
yes i am following the example 6 for single note (as voted) Have not come across multiple notes yet. Will re-check.
Good points. Maybe multiple notes should just be different sentences in the same style as for a single note. Which ends up looking like: <strongNote(s):</strongFirst note goes here. Second note which is a bit longer goes here. Third note which is the longest note of all goes here.
That's a judgement call I think it could be converted. I would hold off on the mult-notes for a little bit - and if you're going to make a PR, it's probably best to try and keep it to maybe one section or so at a time, or maybe a few sections if there's only a couple files changed.
I have a doubt: in , Is the note section considered multi-note or single note? The note section has more than one sentence. Does it qualify as multi-note then?
That one looks like you could probably just put the two sentences together in a single note. Since they are so related. And we aren't sure yet what we want a multi-note to look like.
I agree if they are related a single paragraph note will be fine. However, if it gets to long it may be more difficult for the user to parse the information, and should then be broken up into individual lines. Any Notes section with more than one sentence should still be described as Notes My opinion on the multi-line notes - we should use markdown bullets. It may put a bit of space between items, but they are much simpler to manage when making changes to the markdown. They automatically insert line breaks after each item and don't require verbose HTML wrapping the text. Visually it also looks like a bulleted list. Spacing between bullets can be modified in CSS if needed. It's also easy to replace the bullet with numbers if the order of the note matters. Note vs Notes should be explicit, Note(s) is only useful if you expect someone to add a second Note and they will forget to update Note to Notes, something we should quickly catch in review with the requirement of multiple reviewers. After some conversation with I agree that it really doesn't make sense to have too many notes in a document - we should work to insert the notes into the curriculum, or provide a place for additional information that may not be directly related to the exercise but provide valuable insights/information/resources.
I believe the corresponding Guide article for the challenge is the place where extra information is supposed to go, to avoid cluttering up the challenge itself.
that may be the case but the way it's conveyed is not great IMO. The only link to the guide article is Get a Hint, something many won't click, especially if it's a fairly simple exercise. I also don't see the guide article at all when I search for the exercise title, something we should look into, unless that is by design.
I see guide links when searching for a lesson title (none of the links work right now) - perhaps you searched for a lesson where the guide article is still a stub, and they don't show up or something.
The search indexes have not been updated in over 12 months, so that could be part of this problem.
I just remember that Quincy prefers not to have links going to other places when a user is on the challenge. He believes the challenge should stand on its own or rely on previously introduced material as much as possible. We want people to stay on the challenge until they just can not, which is where the Get a Hint or Ask for Help buttons come into play.
So the single note structure was to the guide with the PR above. The multinote issue wasn't exactly concluded - do we want to continue the conversation? I'm thinking we can close this, and mods should just keep notes small when we can. And multinotes can just be combined into a single paragraph after a
I don't know how many multi-notes there actually are, but I say we just combine them like you suggest in the same paragraph. I can create a PR to reflect this. Then, as we come across the multi-notes, we can first figure out if there even needs to be a multi-note and then probably just make it a single paragraph. How does that sound?
A PR to describe this in the guide? Sure

Discussion:
```` - Additional information in the form of a note should be formatted `<strong>Note:</strong> Rest of note text...` <ins> - If multiple notes are needed, then list all of the notes in separate sentences using the format `<strong>Notes:</strong> First note text.  Second note text.`. </ins> - Use double quotes where applicable ## Formatting seed code