diff --git a/book/CH13_ExtendingTheHyperviewClient.adoc b/book/CH13_ExtendingTheHyperviewClient.adoc
index 5301fc9..cfed661 100644
--- a/book/CH13_ExtendingTheHyperviewClient.adoc
+++ b/book/CH13_ExtendingTheHyperviewClient.adoc
@@ -726,9 +726,25 @@ And importantly, this evolution preserves the Hypermedia, server-driven architec
 ****
 
 
-//TODO astep: wc wrote a basic conclusion here, is it okay? add more?
+//TODO astep: wt wrote a basic conclusion here, is it okay? add more?
 === Mobile Hypermedia-Driven Applications
 
 That concludes our build of mobile Contact.app. Step back from the code details and consider the broader pattern: the Hypermedia-Driven Application architecture allowed for signicant code reuse, and led to a manageable stack for ongoing app updates and maintenance for both web and mobile. 
 
 Yes, there is a story for Hypermedia-Driven Applications on mobile.
+
+
+[.design-note]
+.HTML Notes: Toward Hypermedia-Friendly HTML
+****
+Throughout the book we discuss some of what we have learned about writing hypermedia-friendly HTML. Our advice in a nutshell: 
+
+* Write with the full range of web constituents in mind: people viewing your site in browsers, people listening to your site through screen readers, search and data engines scraping your site programatically, and developers reading your HTML.
+* Stay close to the HTML markup you’re producing and be able to change it. Prefer frameworks and components that extend HTML, rather than abstracting it away.
+* Apply the Locality of Behavior principle to HTML.
+* Familiarize yourself with the full range of available tags and attributes and make them part of your toolkit. Don't restrict yourself to what Markdown can do.
+// we should be able to say the s word by now
+* Aim for good fit between tag semantics and your use case; make frequent use of the HTML specs. When more specific tags don't fit, it is usually better to step back to <div> than to use a tag incorrectly. 
+* Stick with established libraries for UI interactions. If a use case requires an improvised solution, test carefully for keyboard and touch interaction and accessibility.
+* To the extent possible, test your HTML with screenreaders, with a keyboard, with different browsers and hardware, and run linters (while coding and/or in CI).
+****
\ No newline at end of file
diff --git a/book/CH14_Conclusion.adoc b/book/CH14_Conclusion.adoc
index 3737a06..8dd3c81 100644
--- a/book/CH14_Conclusion.adoc
+++ b/book/CH14_Conclusion.adoc
@@ -67,18 +67,3 @@ put the endless swirl of the "`new new`" aside, look back on where the web came
 
 Perhaps it's time to give hypermedia a chance.
 
-[.design-note]
-.HTML Notes: Toward Effective HTML
-****
-Throughout the book we discuss a number of best practices for writing effective HTML. They are, in a nutshell: 
-
-* Stay close to the HTML markup you’re producing and be able to change it. Prefer frameworks and components that help you do this.
-* Apply the Locality of Behavior principle to HTML.
-* Familiarize yourself with the full range of available tags and attributes and make them part of your toolkit. Don't restrict yourself to what Markdown can do.
-// we should be able to say the s word by now
-* Aim for good fit between tag semantics and your use case; make frequent use of the HTML specs. 
-* When more specific tags don't fit, it is usually better to step back to <div> than to use a tag incorrectly. 
-* Stick with established libraries for UI interactions. If a use case requires an improvised solution, test carefully for keyboard and touch interaction and accessibility.
-* Prefer components that extend HTML, rather than abstracting it away.
-* To the extent possible, test your HTML with screenreaders, with a keyboard, with different browsers and hardware, and run linters (while coding and/or in CI).
-****