Adding an example of source lines or notes on the bottom of graphs

[rl-utility-man]

Please uncomment this block and take a look at this checklist if your PR is making substantial changes to documentation/impacts files in the doc directory. Check all that apply to your PR, and leave the rest unchecked to discuss with your reviewer! Not all boxes must be checked for every PR :)

If your PR modifies code of the plotly package, we have a different checklist
below :-).

Documentation PR

• [ X] I've seen the doc/README.md file
• [ X] This change runs in the current version of Plotly on PyPI and targets the doc-prod branch OR it targets the master branch
• [ X] If this PR modifies the first example in a page or adds a new one, it is a px example if at all possible
• [X ] Every new/modified example has a descriptive title and motivating sentence or paragraph
• [X ] Every new/modified example is independently runnable
• [X ] Every new/modified example is optimized for short line count and focuses on the Plotly/visualization-related aspects of the example rather than the computation required to produce the data being visualized
• [ X] Meaningful/relatable datasets are used for all new examples instead of randomly-generated data where possible
• [ N/A] The random seed is set if using randomly-generated data in new/modified examples
• [ N/A] New/modified remote datasets are loaded from https://plotly.github.io/datasets and added to https://github.com/plotly/datasets
• [N/A ] Large computations are avoided in the new/modified examples in favour of loading remote datasets that represent the output of such computations
• [ X] Imports are plotly.graph_objects as go / plotly.express as px / plotly.io as pio
• [ X] Data frames are always called df
• [X ] fig = <something> call is high up in each new/modified example (either px.<something> or make_subplots or go.Figure)
• [X ] Liberal use is made of fig.add_* and fig.update_* rather than go.Figure(data=..., layout=...) in every new/modified example
• Specific adders and updaters like fig.add_shape and fig.update_xaxes are used instead of big fig.update_layout calls in every new/modified example
• [X ] fig.show() is at the end of each new/modified example
• [X ] plotly.plot() and plotly.iplot() are not used in any new/modified example
• [X ] Hex codes for colors are not used in any new/modified example in favour of these nice ones

Code PR

• I have read through the contributing notes and understand the structure of the package. In particular, if my PR modifies code of plotly.graph_objects, my modifications concern the codegen files and not generated files.
• I have added tests (if submitting a new feature or correcting a bug) or
  modified existing tests.
• For a new feature, I have added documentation examples in an existing or
  new tutorial notebook (please see the doc checklist as well).
• I have added a CHANGELOG entry if fixing/changing/adding anything substantial.
• For a new feature or a change in behaviour, I have updated the relevant docstrings in the code to describe the feature or behaviour (please see the doc checklist as well).

-->

[rl-utility-man]

This documents a work around for the canonical problem that Issue 3084 proposes to solve.
cc: @joerecht

[rl-utility-man]

@gvwilson Please advise about a road forward on this documentation PR. I'd welcome clarity about whether it is useful and, if so, how to revise and publish it. I see @LiamConnors was unassigned and then unassigned. I'm looking forward to engaging with the right person. I am honored to work with the Plotly team to make this project more useful.

[LiamConnors]

@rl-utility-man sorry for the delay. I'll take a look at it this week

[LiamConnors]

Thanks for the effort on this one @rl-utility-man
I like the idea. When I tried the example, some of the text is cut off

Makes me wonder if it's just maybe too specific of an example for the docs. Will it be difficult to get it working if your text looks different or you're running it in a specific environment?

[rl-utility-man]

Good point about the cut off text! I reworked the example with short text that works well at a wide variety of screen resolutions and added a comment to the code warning about over long text getting cut off. I also rewrote the comments and documentation text to clarify out the general points I am trying to make with this example. Let me know what you think of the revised version.

[rl-utility-man]

@LiamConnors Please let me know if my edits make this useful documentation and addressed your concerns. I think this example consolidates insights that would otherwise require reading and thinking about several different sections of the documentation. Many thanks!

[LiamConnors]

@LiamConnors Please let me know if my edits make this useful documentation and addressed your concerns. I think this example consolidates insights that would otherwise require reading and thinking about several different sections of the documentation. Many thanks!

Thanks @rl-utility-man! will try this out tomorrow

[LiamConnors]

Suggested change

	```import plotly.express as px
	df_iris = px.data.iris()
	fig = px.scatter(df_iris, x="sepal_width", y="sepal_length", color="species",
	size='petal_length', hover_data=['petal_width'])
	#Use the title for the source / note line
	```python
	import plotly.express as px
	df = px.data.iris()

For the examples in the docs, if there's only one dataframe in that example, we suggest always calling it df for consistency

[LiamConnors]

Suggested change

	This example shows how to put a terse note about the data source or interpretation at the bottom of the figure. This example achieves the desired alignment in the bottom right corner using the title element and container coordinates and then uses an annotation to add a figure title. A near zero container coordinate is an easy and robust way to put text -- such as a source line or figure note -- at the bottom of a figure. It is easier to specify the bottom of the figure in container coordinates than in e.g. a paper coordinate since uncertainty about the size of legends and x-axis labels make the paper coordinate of the bottom of the figure uncertain. Making the y container coordinate very slightly positive avoids cutting off the descending strokes of letters like y, p, and q. Only the title command supports container coordinates, so this example repurposes the title element to insert the note and repurposes an annotation element for the title. The top of the figure is typically less cluttered and more predictable, so an annotation with its bottom at a paper y-coordinate slightly greater than 1 is a reasonable title location on many graphs.
	This example shows how to add a note about the data source or interpretation at the bottom of the figure. This example aligns the note in the bottom right corner using the title element and container coordinates and then uses an annotation to add a figure title. A near zero container coordinate is an easy and robust way to put text -- such as a source line or figure note -- at the bottom of a figure. It is easier to specify the bottom of the figure in container coordinates than using paper coordinates, since uncertainty about the size of legends and x-axis labels make the paper coordinate of the bottom of the figure uncertain. Making the y container coordinate very slightly positive avoids cutting off the descending strokes of letters like y, p, and q. Only the title command supports container coordinates, so this example re-purposes the title element to insert the note and re-purposes an annotation element for the title. The top of the figure is typically less cluttered and more predictable, so an annotation with its bottom at a paper y-coordinate slightly greater than 1 is a reasonable title location on many graphs.

Just made a few small edit suggestions (not as many as the diff suggests). For example, it looks like it's this is a direct comparison between paper coordinates and container coordinates. Is that right? Then, I don't think we need to say "e.g"

"than in e.g. a paper coordinate since uncertainty"

[LiamConnors]

Suggested change

Could this line go?

[LiamConnors]

Suggested change

	# Aligning this flush with the right edge of the plot area is
	# predictable and easy to code.
	# Putting the title in the lower left corner, aligned with the left edge of the axis labeling would
	# Aligning this flush with the right edge of the plot area is
	# more predictable and requires less configuration
	# Putting the title in the lower left corner, aligned with the left edge of the axis labeling would

Would this also be true? I think it might make it more precise. What do you think?

[LiamConnors]

Looks good to me @rl-utility-man. Thanks for adding this! I just left a few additional comments.