The “what” in “what you see is what you get” is not always “formatting”.
Authors need WYSIWYG (What You See is What You Get) displays to work effectively. This is basic ergonomics. If you can’t see the thing you are supposed to be creating, you will have a hard time creating it well.
But while authors always need WYSIWYG displays, the “what” that they need to see is not the same thing in every case. There can be several different values for the “what” in WYSIWYG.
The term WYSIWYG was coined to describe the displays of word processing and desktop publishing programs. In this case, the “what” was the formatting of the printed document. (At the time we were talking strictly about printing on paper. The “what” you saw on screen was the “what” that was going to appear on paper — more or less.)
This was a big step forward, but the step forward was not enabling people to do typesetting with computers. Doing typesetting with computers had been possible for a long time using a language called TeX, which is still used in some places today. But TeX, has never been widely used because while you can specify formatting with great precision in TeX, you can’t see the formatting that you are specifying as you work. You can only see it afterward when you run the file through the TeX program to create formatted output.
Make a mistake in your TeX markup, and your output may be garbled in ways that make it hard to find your error, and finding and fixing errors can be fiddly and tedious. Desktop publishing was a big step forward because it allowed people to see the formatting they were creating as they created it.
But formatting is not always the “what” in WYSIWYG. In Learning Python, Mark Lutz describes the syntax of the of the Python programming language as WYSIWYG.
Python is a WYSIWYG language — what you see is what you get — because the way code looks is the way it runs, regardless of who coded it.
Lutz, Mark (2013-06-12). Learning Python (p. 326). O’Reilly Media. Kindle Edition.
What he means in this case is that with Python, unlike most other programming languages, the indentation of the source code always shows the logical structure of the program. If formatted poorly, the indentation of code in a C or Java program can be completely misleading as to the actual structure of the code. Lutz provides this example:
if (x) if (y) statement1; else statement2;
Here the formatting of the code makes it appear as if the else statement belong to the first if statement, but it doesn’t. It actually belongs to the second if statement. The structure you see is not the structure you get. In Python, such confusion cannot occur. Lutz’ Python example looks like this:
if x: if y: statement1 else: statement2
In this case, the else does belong to the first if, as it appears. If it were indented under the second if, like this:
if x: if y: statement1 else: statement2
then the else would belong to the second if statement
In Python, the indentation of the source code determines the structure of the program, and thus the logical structure you see in the source is the actual structure you get in the program. Thus Lutz chooses the term WYSIWYG to describe the language. But in this usage of WYSIWYG, the “what” is not formatting, but structure.
In content engineering there are multiple possible “whats” you might want from a WYSIWYG display. Desktop publishing is based on the premise that the author is also the designer, the typesetter, and the prepress person, so the “what” is formatting. We can be more explicit about this by substituting the word “formatting” for the word “what” in the acronym: FYSIFYG (the Formatting You See Is the Formatting You Get). The desktop publishing approach requires a FYSIFYG display.
Before the days of desktop publishing, when authors were only required to worry about the text, and did not have to wear a dozen other hats, they got by with pens or with typewriters. Both these tools had a TYSITYG display: the Text You See Is the Text You Get.
Today, however, the increasing demand for malleable and repurposable content means neither TYSITYG not FYSIFYG will suffice. We need more than just the text, and something other than text plus formatting. We need structure. What we need to create structured content, therefore, is a SYSISUG display: the Structure You See Is the Structure You Get. Creating such a display, alas, has not been easy.
It might seem like a raw XML file is a SYSISUG display, because all the structure is there in the XML tags. Many XML editors that let you switch to a view of the raw XML will call this “the structure view”. The problem is, while the structure is there, it is not in the least easy to view. There is way too much syntactic noise in an XML file for the reader to easily discern the structure it expresses, as this chunk of the DocBook source for my book shows:
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="chapter.linkrichly"> <title>EPPO Topics Link Richly</title> <indexterm><primary>Weinberger, David</primary><secondary>on linking</secondary> </indexterm> <blockquote> <attribution>David Weinberger, <citetitle pubwork="book">Too big to know</citetitle> <biblioref linkend="TooBigToKnow"/></attribution> <para><indexterm class="startofrange" xml:id="idx.linking-1"><primary>linking</primary></indexterm>Links are the visible manifestation of the author giving up any claim to completeness or even sufficiency; links invite the reader to browse the network in which the work is enmeshed, an acknowledgement that thinking is something that we do together.</para> </blockquote>
Just as the syntax of a formatted poorly C of Java program can obscure the program structure, so the syntax of an XML file can, and usually does, obscure the structure of the content. (Careful indenting of the XML can help, but there is so much syntactic noise in an XML file that it can still be difficult to read.)
This is exactly what Lutz is talking about in describing Python as WYSIWYG in comparison to C and Java. In C and Java, the structure is all there, but it may be expressed in a way that can be hard to see. And if you can’t easily discern the structure inherent in the code you are reading, it is not really a SYSISYG display, because while the structure is there, you can’t actually “see” it at a glance. You have to parse it out carefully from the syntax, and that does not make for effective authoring.
Another alternative that XML editors sometimes offer is a tree or grid view. Here is the same passage in grid view. Here the structure itself is quite explicit, but the text whose structure it expresses is no longer easy to read. You can see the structure, but not the thing the structure applies to, which is pretty much the same thing as not seeing it at all. While the grid view of an XML editor can be useful for many purposes, it isn’t a good place to author content. The tree view of XML is not SYSISYG.
Most XML editors also offer a formatted view (often called, “author view”, or something similar). This view looks superficially like the FYSIFYG display of a desktop publishing program. There are two problems with this view, however. First, though it looks like it, it is not really a FYSIFYG view because there is no guarantee that the formatting the writer sees on screen will be the formatting that the reader sees on whatever device the use to eventually view the content.
Below is the author view of the same passage from my book, using the editor’s default authoring style sheet for DocBook. As you can see, much of the structure expressed in the XML and visible in the grid view is invisible here. This is not a SYSISYG view of the content.
Some of the structure does show through here, though. The index elements are partially visible and the big quotation marks set off the block quote. This is necessary, otherwise the author would have no idea they were there (and might delete them unwittingly) but it means that this is not a FYSIFYG view either. Nor is it a TYSITYG view, since those same elements are not part of the actual text of the book.
So if the “what” in this supposedly WYSIWYG view of an XML document isn’t formatting, and it isn’t text, and it isn’t structure, what is it? Unless someone can suggest some other value of “what” that applies, we have to conclude that this view is not WYSIWYG in any meaningful sense.
And that’s a big problem, because it means that none of the common views offered by a typical structured editors is actually a WYSIWYG view. In particular, since structure is what we care about in structured writing, none of the views is actually a SYSISYG view. In short, we are asking authors to create structure without providing them with an authoring view in which they can actually see the structure they are supposed to be creating.
If anyone was wondering why XML can be such a hard sell to authors, this is one of the biggest reasons. Authors need a WYSIWYG display. The “what” can be different in different cases, but whatever it is, text, formatting, structure, or something else, they need to see it in order to be sure that they will get it. They need an interface that is TYSITYG, FYSIFYG, or SYSIFYG, or xYSIxYG according to the task at hand.
How to provide an effective SYSISYG (and therefore appropriately WYSIWYG) view to the author is perhaps the single most pressing problem in structure authoring. The failure to provide one is perhaps the biggest thing holding back wider adoption of structured authoring methods. We are not likely to move structured writing beyond a small cadre of highly trained full time authors until we solve this problem.
Python provides a SYSISYG view of programming code, but it does it by creating a whole new syntax. That is something that can be done for content too. Markdown and reStructured Text both provide an alternate syntax for HTML documents, as does wiki markup. All of these provide a workable SYSISYG syntax for HTML web pages.
But none of these provide the generality and extensibility of structure that XML provides. And in most cases, structured authoring applications require more structure, and more specific structure, than HTML provides (even for people writing solely for the Web). As long as we are in the XML world, we are going to have to look elsewhere for our SYSISYG view.
One place we can look is a place that SYSISYG views are commonly found in every day life: forms. The forms you fill out all the time, from an order form, to a registration form, to your annual tax form, are all structured views. Any of these functions could also be performed by a narrative view. You could order, or register, or report your earnings and deductions by writing a letter. Chances are, though, that if we relied on that system lots of people would forget to include important information, and people receiving the letters would have to put a lot of time and effort into getting the required information out of letters that put the information in a different order or called it by different names.
For these applications to work smoothly, we need a structure to guide the authors to supply complete information using agreed terms, and to make it easy for the recipients to get the information out. To get this structure, we need to provide the authors with a SYSISYG view, and we do this using forms.
Forms can provide a SYSISYG interface for a variety of content creation tasks. I have been developing forms-based authoring interfaces for many years. Fortunately, advances in tools are making it easier to create such an interface. For instance, here is a recording of a webinar I did with George Bina of SyncroSoft (makers of the oXygen XML Editor) on the case for forms-based authoring.
Forms-based authoring is probably not the whole answer to achieving effective SYSISYG authoring, but it is a big step in the right direction, and something that is available to use today.
The quest for a better SYSISYG interface for content authoring must continue, however.
I always learn something from your posts, Mark. In this case, I learned that the formatting of Python code determines the relationship between statements. Pretty cool. I’ll have to investigate Python a little. As to the proposal of forms-based authoring as a solution to xYSIxYG, I don’t see what it solves. Forms are incredibly useful, even necessary, when one requires the information in a certain format and order. Most tech writing is not so predictable. How can a form anticipate the combination of elements that a writer might need for a particular topic? I suppose it might be possible to create a master form that allowed the dynamic insertion of sub-forms for a paragraph, list, image, table, or whatever. The effectiveness then depends on the writer knowing the functionality of the master form well enough to know to insert the correct sub-form for a list, for example; the writer has to go through a mental process such as, “I want to add a bulleted list here, so I need to go to the Insert menu and select List Form and then in the dialog box I need to select Bulleted.” I don’t see how that is any different than “I want to add a bulleted list here, so let me type all of the list items and then select them all and apply the Bulleted paragraph format.” Or even “I want to add a bulleted list here, so I need to insert a ul element and then a few li elements.” All of it requires a preconceptualization of what kind of information you’re creating. You have to know you’re creating a list in order to create a list and then you might as well identify it as a list, period. It’s just the application- or framework-specific method of indicating the nature of the information that differs…form, word processor, XML editor. Whatever its format, the form just seems to serve as an intermediary that has as much of a learning curve as the thing it’s trying to simplify.
Thanks for the comment Leigh,
In the case of the Oxygen form capability, the form is actually just a format applied to the underlying XML document, so it does not have to anticipate everything the author might want to write. As new sections or elements are added, they are automatically styled as form fields. The point then being that styling them as form fields shows the structure of the document in a clear way.
As for adding elements, you can add buttons to the form interface to add new elements to the document. This avoids a common problem in the document formatted view where you have to get your cursor into the right place in the document in order to add the element you want. In some cases, there can be half a dozen different positions in the white space between two elements, each of which is in a different element, each of which allows different sub-elements to be added. (Adding a para to the current list item vs. adding a new list item vs. adding a new para after the list, vs adding a new subsection after the list, vs adding a new section after the list.)
Buttons on the form remove this problem because their insertion point is determined by their place on the form, not the position of the cursor (different buttons for each of the additions listed above. Also, they can be programmed to add any amount of XML you want, so they don’t just do one element at a time. You can also add help text right onto the form. Taken together, these tools can greatly reduce not only the leaning curve, but the amount the author has to learn (which is what good forms do in other domains: instruct in the context of a clearly defined task).
All that said, forms will not work for everything (which is why I said at the end of the post that the search for a SYSISYG interface must continue). Forms can only handle a limited amount of complexity and a limited range of options before they become unworkable. I can’t imagine a forms-based editor for DocBook, for instance, despite using it to illustrate the post. It is just way to big and too loose for the constrained environment of a form.
On the other hand, a constrained environment is just what you want if you are asking an occasional author to contribute structured content. (Reducing the learning curve by reducing the amount you need to learn.) You want to constrain their choices to just what you need from them, both to make the task easier for them, and to ensure that you get what you need in the form you need it.
In many cases, therefore, taking a forms-based approach has to go hand in hand with the use of a constrained schema. (In DITA this could be done by specialization or constraints.) Alternatively, though, you could use the form itself as a constraint mechanism, offering only a limited set of options through form controls while keeping a generic topic schema underneath.
You are quite right about the overcomplexity of most XML being self-defeating. But it doesn’t have to be that way. We’ve come up with a new document markup language, uDoc, that addresses this very issue. I tried to include the quote you have above as an example, bet kept getting a 404 from your site.
Have a look at the uDoc spec, in the repository at the site above; It contains quite a few quotes from your blog… 😉
Thanks for the comment, Jeremy
That’s an very interesting project you have, and I am very flattered to be quoted so often in the spec.
My question would be, I can see how Micro XML makes live simpler for the application developer. Fewer, simpler constructs with fewer, simpler rules make for fewer things the application has to handle. But in terms of authoring, MicroXML seems to have the same verbose syntax as regular XML. Perhaps it makes it easier for the author to learn XML, but does it make it easier for them to see the structure for the document they are writing?
Yes, it does make it easier, specifically with its “tag minimization” feature, discussed in section 1.6 of the spec. John Cowan, the co-creator of MicroXML,was kind enough to work with me on this, and adding the udx utility described in Appendix E was his idea. If you look at the examples of code in the spec, or at the spec source code itself, you’ll see a drastic reduction in clutter, and a concomitant improvement in seeing the structure. Yet it is always valid MicroXML. The minimization, like element definition, is user-extensible very simply, literally in a minute or two. So you can eliminate verbosity wherever you want, easily, no forms interface needed.
Our whole design intent with uDoc was to make *authoring* better; any improvement for the *processor* was just gravy.
O cool! So MicroXML restores tag minimization! Okay, I will have to look at the spec and at your document in more detail now.
To be precise, it’s not MicroXML that restores tag minimization, it’s uDoc. While XML normally acts as a nesting set of containers, labeled at both ends, the minimized form of uDoc sees *events*, which require only single empty tags. John was concerned about that at first, and wanted a utility to convert from minimized to full-tagged form for the benefit mainly of XSLT processing. I wrote that, and made it two-way; the containers and events are really isomorphic views, so switching is lossless.
In addition to that kind of minimization, which is especially effective in tables and lists, uDoc does three other types, all handled by the same utility. One is wiki-type markup for some character tags, including ^tag^ for the usual XML tag form. The others are removal of p tags wherever possible, such as between text paragraphs, and removal of them from within block elements like li and td. Each sounds minor, but put together you get a drastic decrease in the markup with no loss of functionality. And that makes the markup that remains very clear in showing structure. Less really is more.
Leigh, I agree that using forms for editing arbitrary structures is not feasible due to the complexity. But they are very well-suited for creating customized UI for smaller and well-structured parts of a document. By “well-structured” I mean chunks whose structure doesn’t change (much or at all) depending on any of the content you are putting into them. For example, you might see how a form-style layout for editing the metadata section of a DITA topic could be effective. This example also suggests that at least some dynamic ability in the form is also useful. E.g. Imagine there being a labeled text box for entering a keyword, and then an “add another” button that allows you to add more text boxes to the form if you need to add more keywords.
XMetaL has allowed users to create forms for editing interfaces for at least 11 years (I don’t know the history of this feature before that). Many of our customers have done exactly the things I’ve just described with success.
Btw, Mark, we sometimes use the term WYSIOO — What You See Is One Option — when we are educating people about this basic principle of structured authoring, i.e. how XMetaL (or any tool) is displaying the content in *a* way that it could look, as opposed to *the* way it could look. IMO one of the primary goals of the non-source-code authoring view (in XMetaL or oXygen or other similar tools) — and a key requirement for developing the style sheets for it — is to display the content in a way that allows the writer to *deduce the markup* based on the styles, as much as possible anyway.
Thanks for the comment, Tom.
I was not aware that XMetal had forms capability, so thanks for pointing that out. As you point out, one option is to use forms for just part of the interface to a document. The things you suggest, like putting add buttons next to fields, is just the sort of thing I am talking about. It’s great because not only does it make it easy to add a field, it makes it clear that you can add a field, which is not clear at all in a document interface.
Everyone seems to have their version of the WYSIOO acronym (though technically, the document view in most cases is not showing any of the actual output options faithfully — things like page and line breaks are not correct for a start). In fact, one could argue that XML was designed based on a faith that the WYSIOO model would work, which lead to the dropping of all the markup minimization features of SGML. Authors were never supposed to see the XML, so it was not supposed to matter how verbose it was.
But WYSIOO had never really worked. Most full time XML authors flip back and forth between the WYSIOO view and the raw tag view regularly because some editing chores are impossible to do accurately in WYSIOO. (This is reminiscent of how Word Perfect users used to flip back and forth between document view and tag view.) Occasional authors just give up in frustration. And the WYSIWYG HTML tools used by most Web CMSs produce markup so hopelessly corrupt and convoluted that it cannot be used for anything other than display.
The real problem for structured writing, I would suggest, is precisely that authors can’t deduce the markup from the styles (as the Web CMS quality HTML demonstrates), in part because a lot of the structure you want does not have a direct style analog, and numerous structures that do have identical style analogs. Deducing markup from style has been the working theory of the industry for many years now, and at this point I think we have to admit that we are not going to be able to make it work for a wide audience. It’s time to start exploring other avenues if we want to broaden the reach of structured content technologies.
Good post, Mark. I agree with nearly all of it (I’ve been writing a long blog post on this subject for a couple of months — it’s probably far too ambitious and is taking an interminable time to write. But anyway, it will be a reply of sorts, whenever I finally hit “Publish”.)
For now, two thoughts about your points in this comment. The “Tags On” view in XMetaL and Oxygen is a good compromise between control and feedback/usability. Not for part-time authors, probably, but good for people who spend much of their day in the editor. Certainly, our authors use it all the time and hardly ever use the plain text view. And I believe inline “tags-on” elements can be displayed within a form, though I haven’t tried it yet.
As for the problem of corrupt markup, the key is using an editor that simply doesn’t allow it, and also constraining the content model appropriately (for example, not allowing mixed content within a list item; text should be within a paragraph element). A good example of this in action is this particular configuration of SDL Xopus: http://xopus.com/demo/simple (there are other configurations on the same site but I think this one demonstrates the point best).
Thanks for the comment, Joe.
I agree that current XML Editors are workable for full time authors with the appropriate training. They remain horribly complex, but perhaps no more so than the horribly complex DPT or HAT tools they are used to using. None of this will fly with casual users, and even full time authors in non-technical roles, who don’t have the inherent interest in tech that drives people into tech writing.
And yes, you can build an editor that only allows valid actions, but then it has to explain to people why it is not letting them do what they want to do, and that will frustrate and confuse the casual user. You won’t get the errors, but you also won’t get the content.
All this was tolerable when we were using structured writing to create standalone books or CDs. But we live in a world of interconnected information now, and we are not going to be able to bring structure and all its advantages to that world with our current approaches and tools.
There is an interesting article from someone at IBM that raises this question of the role of structured authoring in a world of connected information: http://jaymanalotoibm.wordpress.com/2013/12/23/killing-xml-and-ia-with-social-media/. I’ll be commenting further on this article in an future blog entry.
Structure existed before markup, and much of it is implicit through formatting. We understand that a section title implies a section, which ends with the next section or the end of the current chapter. A reader relies on this structure to understand how the information is organized, so the author needs the visual representation in order to properly guide the reader.
But markup also enables processing, and some markup has nothing to do with structure. Much of the ‘syntactic noise’ in your example is only noise in the context of structural markup. The processor relies on this markup for various tasks, such as generating an index and a bibliography. Within this context, much of the structural markup would be syntactic noise. The author also needs a way to manage this information, and forms may be the right approach.
I would thus agree with Leigh White that forms aren’t right for authoring most content; and also with Tom Magliery that a forms interface can be quite useful for metadata and other well-structured components – particularly for assuring quality of that information. Unless the author is expected to have access to and understanding of the raw markup, what he or she needs is appropriate (i.e. selectable) access to both the processing-specific markup and the document structure.
Thanks for the comment, Tom.
I always make a distinction between rhetorical structure and computable structure. There is a level of rhetorical structure in a document that can be inferred from headings, but there are also much more specific rhetorical structures which, while they may be expressed through headings, are much more particular than merely being a heading.
One of the examples I refer to in my book is a configuration guide for an embedded operating system in which it was essential to the user to be able to track the components of a system that are impacted by a change in another component (because any affected component would have to go through a very expensive re-certification). The configuration guide was set up specifically to support this, which each topic having a very specific structure designed to allow the user to trace the influence of every component exactly. It even including a dependency diagram which ideally should have been generated from data rather than drawn by hand.
If you looked at that document without any of this background information, you would simply see a familiar structure of headings, subheadings, and graphics, typical of any tech comm manual or topic. But there was in fact a much more specific rhetorical structure there, driven by a very real and specific business need.
We created specific markup to reflect and enforce that rhetorical structure. But you could not have divined the structure from output, unless you had read many examples and noticed the similarities in headings, diagrams, and the way certain things were expressed.
To author this material successfully, you would have to understand this structure. A forms-based authoring environment would be able to put this structure explicitly in front of the author, educate them on the structure, and guide them through creating it.
The raw markup of that topic would have been full of syntactic noise as well — some of the structured were quite intricate (on purpose, because they needed to be precise). But that semantic noise was not for things like indexing. (Perhaps I should have chosen that project for the blog post, though that would have necessitated a good deal of redaction.)
All that said, I agree with you on your final point. We are in a situation now where authors require dual views to work, which in turn implies that they need a great deal of knowledge of markup, and of the specific markup they are creating. And the problem with that is that is limits structured writing to a very small cadre of authors. What I am looking for in a SYSISYG interface is a single interface that can be used by a wider array of authors.
Part of that, though, is going to have to involve a change in how we design markup, not just a change in interface. A great deal of what you (rightly) call the processing markup really doesn’t need to be there. The processing it specifies could be derived from metadata on the back end. The presence of processing-oriented markup in the structures authors are asked to create is another big impediment to the wider spread of structured authoring.
A couple of issues:
– XML Structure is sometimes so complicated it is self-defeating. Well – at least if the flavour of XML you’re using is DITA, you can do several things to make that better: Constrain, specialize, use forms based editing (as in oXygen or Xmetal), or use a so-called “author view” that cleans up the screen, shows you structure (sometimes in a separate panel), and can still be validated. Adobe provides this in its XML editor, and all the other mainstream XML editors most of use use, such as oXygen, Xmetal, Arbortext, have their equivalents.
– I have already suggested yet another acronym – WYSIWYN – What You See is What You Need. This covers most or even all of the contexts Mark describes. It also covers the notion of “comfort-based” formatting – i.e. formatting that is not intended – and doesn’t pretend – to show you the layout you’ll get in your final “document” – whatever that might mean. Rather, it’s formatting that simply makes it easy for the author to se what s/he is doing. Conventions such as bold text for an tag are just that – we don’t care how that will be rendered in one output format or another, we like seeing it that way on our editing screens because it helps us understand what we’ve done.
Sometimes, “What you need” is formatting. Sometimes it’s structure. Sometimes, it’s both or yet again something else. WYSIWYN is a concept that goes with Kanban information delivery: getting all the information you need, only the information you need, delivered where and when you need it, and otherwise staying out of the way.
I also like it because the “WYN” part sounds like “win” and that’s what we do when we work this way.
Thanks for the comment, Ray
“XML Structure is sometimes so complicated it is self-defeating” — yup. Agree absolutely. But the moguls of the markup world insist we must all write in a single form common to all, so of course it is hideously complicated.
To my mind, the first principle of structured writing is mutability. The reason we create structure at all is so we can manipulate the content. The key to being able to manipulate it successfully, however, is highly reliable structure, which you don’t get when you are people to use incredibly complex markup. Self defeating indeed.
And the point about mutability is, if you want to change the content into some other form for exchange, you can, as long as your markup is reliable. So focus on capturing semantics reliably and your content will be compatible with all the world-spanning markup standards out there. Try to write into any one of them, however, and you will probably end up with something that is not even reliable enough within the system you wrote it in.
And yes, WYSIWYN would encompass SYSISYG, in cases where structure is what you need. The trick is to actually create such an interface, because right now we don’t seem to have one.
I like the phrase “comfort-based” formatting. I think it describes exactly why people cling to so-called WYSIWYG interfaces for structured writing. But it is not simply because that is what they were used to in the DTP world. It is because we have failed to provide them with a comfortable way to create structure. I have done enough of these projects over the years to know that when you do give people a SYSISYG interface, they get comfortable with it very quickly. The problem is, it still costs too much to do it, and the tools and techniques for doing it are still not widely know. That is the problem I believe we have to fix if we want to make structured writing comfortable for more than a limited number of full time authors.
that should be, in second point, 3rd line from bottom emphasis tag (emphasis)