In Praise of Long-form Content

Yesterday I wrapped up work on my new book on Structured Writing and delivered it to the publisher. There will be more work to do, of course, after the pre-publication review process is complete, but in a broad sense, the book is done. That is, the arc of the book is complete.

Good books have an arc. Finding that arc is one of the great joys of long-form writing. Of course, this blog is about short form writing — about Every Page is Page One topics that serve a single discrete purpose for the reader. But in a sense even a book should fit that mold — should serve a single discrete purpose for the reader. The whole should be more than the sum of the parts. There should be an arc, something the book says that is more than an accumulation of details, and that allows the reader to see the details in a new light — and to act differently and, hopefully, more successfully, in that new light. read more

DocBook resurgent: what it tells us about structured writing and component content management

A new XML-based content management system that is not based on DITA. Bet you didn’t see that coming. But I think it tells us something interesting about the two sides of structured writing.

Tom Johnson’s recent sponsored post explains the origins of Paligo, a relatively new CCMS out of Sweden. Paligo was developed by a company that had formerly been a DITA consulting shop in an attempt to come up with something that was easier to use (and less expensive) than the DITA solutions they were implementing.

What is interesting to me about Paligo is that they chose DocBook rather than DITA as the underlying XML vocabulary. Why? Quoting Tom:

And it turns out that building on a foundation of Docbook XML is considerably easier than building with DITA. DITA tends to impose more restrictions about what you can and can’t do, Svensson says. Even so, Paligo is only “based on Docbook.” Paligo extends from this foundation, adding what they need and not letting the content model restrict the system, while maintaining full capability to export to the open standard.

This is interesting because DocBook is a large and complex specification. (I want to say larger and more complex than DITA, but I’m not sure if that is true anymore.) Why use it as the basis for what is supposed to be a system that is easier to use than DITA?

The answer seem to be lack of restriction. DocBook may be as large and as complex as DITA, if not more so, but it is much less restrictive. DITA has lots of restrictions on what you can and cannot do in each topic type. DocBook has very few. You can combine DocBook elements in just about any way that might occur to you. And apparently Paligo loosens DocBook even further.

Why is this significant? In a CCMS (Component Content Management System) the whole point of the system is to let you assemble documents out of pieces. The main benefit of this is content reuse. The main problem standing in the way is composability: the ability to put pieces together and have them work.

Composability is an interesting problem. Lego sets and Mechano both have composability within their own systems, but there is little composability between Lego and Mechano.  You cannot freely exchange the bits. Composability is similarly a problem between the many different file types used across a typical enterprise. If you want to practice component content management on an enterprise scale, you need a composable format across the enterprise.

There are two ways to get this. One is to allow each group in the enterprise to have their own format, but insist that it must be transparently convertible into a common composable format. The other is to get everyone to use the common composable format directly. The latter sounds easier, so that is what most people choose. (It is not always easier, but people only find that out later.)

To get everyone in the enterprise using a single composable format, you need it to be easy to use, as well as being flexible enough to serve everyone’s needs. What to choose?

DITA has been the default choice for a while now, but the problem is that DITA is not really easy to use. Several companies have tried to make DITA easier to use. (Tom mentions EasyDITA in his article.) But DITA comes with restrictions and restrictions are hard to learn and annoying to comply with unless you really understand the point of them.

Lightweight markup languages such as Markdown and ReStructuredtext have become popular as well, with various CMS and publishing systems being built around them. But while they are simple and easy to use, their simplicity can be limiting. There are things that occur in complex publications that they cannot easily represent.

DocBook offers a far richer set of markup structures that can represent all of these things, but without the restrictiveness of DITA. It makes sense, therefore, for a company like Paligo to choose it for their underlying document structure.

There is a rub here though, and it has to do with the two sides of Structured Writing that I mentioned at the beginning. Those two sides are composability  and constraint. I am writing a book about structured writing (currently being serialized on TechWhirl) . That book focuses on the constraint side of structured writing.

The constraint side of structured writing is about expressing and enforcing constraints on content. It is about limiting and shaping what is written to meet a particular need. For example, it may constrain a recipe to follow a particular format and include particular pieces of information.

Here is a constrained version of a recipe:

recipe: Hard Boiled Egg introduction: A hard boiled egg is simple and nutritious. ingredients:: ingredient, quantity eggs, 12 water, 2qt preparation: 1. Place eggs in pan and cover with water. 2. Bring water to a boil. 3. Remove from heat and cover for 12 minutes. 4. Place eggs in cold water to stop cooking. 5. Peel and serve. prep-time: 15 minutes serves: 6 wine-match: champagne and orange juice beverage-match: orange juice nutrition: serving: 1 large (50 g) calories: 78 total-fat: 5 g saturated-fat: 0.7 g polyunsaturated-fat: 0.7 g monounsaturated-fat: 2 g cholesterol: 186.5 mg sodium: 62 mg potassium: 63 mg total-carbohydrate: 0.6 g dietary-fiber: 0 g sugar: 0.6 g protein: 6 g read more

Another demonstration that language is stories

Sam Jackson makes it look easy, but Siri and her cohorts are still pretty dumb. If experience alone does not illustrate this to your satisfaction, a recent article in the MIT Technology Review, Tougher Turing Test Exposes Chatbots’ Stupidity, shows just how low their success rate is in understanding real language.

The Winograd Schema Challenge asks computers to make sense of sentences that are ambiguous but usually simple for humans to parse. Disambiguating Winograd Schema sentences requires some common-sense understanding. In the sentence “The city councilmen refused the demonstrators a permit because they feared violence,” it is logically unclear who the word “they” refers to, although humans understand because of the broader context. read more

Affordances are relative

Affordances, those features of a product that help you figure out how to use it, are relative.

Most of the busses in the Kitchener-Waterloo region have rear doors that open when you wave your hand in front of them. The one I took downtown this morning must have been an older model because it just had two vertical push bars on the doors.

When we arrived at the terminal, the young woman at the front of the queue to get off started to wave her hands in front of the door, which did not respond. Puzzled and alarmed, she began to shout at the driver to open the doors, until someone behind her said, “push the handle”. read more

Why we need constrainable lightweight markup languages

This post is in response to a Twitter conversation that started with:

This led to a discussion about extensibility and constraints in markup languages. Markdown is a pretty simple lightweight markup language (and popular for that reason) but it is what it is. You can’t add anything to it except by creating your own variant by modifying its code (which lots of people have done). read more

Can Content be Engineered; Can Writers be Certified?

tl;dr: We can apply engineering methods to content development, but we do not have the body of proven algorithms or known-good data to justify formal certification of communication professionals the way we have for doctors and engineers.

We talk about content engineering. I call myself a content engineer sometimes. But can content really be engineered? Is content engineering engineering in the same way that engineering a bridge is engineering, or only engineering by analogy?

This post is prompted by a fascinating conversation with Rob Hanna and others at the monthly STC Toronto Networking Lunch. The conversation morphed into something I think I can fairly characterize as: is there a uniform methodology to technical communication, one that can form the basis of a curriculum, a certification, or a toolset, or is there a legitimate diversity of approaches, roles, methods, and tools. read more

Writing Excellence Through Domain Awareness

A little while back, Tom Johnson posted an article entitled Seeing things from the perspective of a learner in which he says, “The balance between knowing and not knowing is the tension that undergirds the whole profession of technical writing.”.

I think that is absolutely correct. The point, after all, is to assist the reader on their journey from ignorance to knowledge. I say assist, because this is not a journey that can be accomplished simply by reading. The reader has work to do to integrate their knowledge. They need to get their hands dirty. But a sympathy with the troubles and perils of that path is at very least, highly useful to the writer.

This does not mean that ignorance is a virtue, as some writers suggest? You do not gain any sympathy with the troubles and perils of the path from ignorance to knowledge without actually learning, and once you have learned, you write from knowledge, not ignorance.

But if you are taking that journey, Tom suggests, you should stop and make notes along the way. Record your questions and your difficulties so that when you arrive at the state of knowledge you have preserved you memories of the road and can use them to inform the travel guides you write for the next traveller.

All this is important because of the curse of knowledge, the cognitive bias that makes you forget the perils of the journey once you reach your destination. As I have suggested in the past, the journey from ignorance to knowledge consists of learning stories, and the way language works is by encapsulating stories in a way that makes us forget that they are stories.  Notes from the road seem like an excellent way to inoculate ourselves against the curse of knowledge by reminding ourselves of the stories we had to learn and the price we paid to learn them.

Still, I am not entirely comfortable with the conclusion that Tom draws from this. Tom summarizes his argument with this diagram:

goodspacesforwritingdocs-01

It is the part about the space between knowledge and ignorance being the place you write the best documentation that bothers me. It is certainly the best place to gather useful notes on the journey from ignorance to knowledge. But I am uncomfortable with the suggestion that it is better to write in a state of partial knowledge rather than full knowledge.

All the same, I recognize that in the state of full knowledge one is apt to suffer from the curse of knowledge. So mere knowledge is not the best place to write from either.

So where does the best technical writing come from. What state do we need to be in to produce the best possible technical communication?

I think we have to reach for a different state, one which I will call domain awareness. I’ll diagram it like this:

domainawareness

Mere knowledge of a subject does not constitute domain awareness. We may understand the subject matter of the domain, but we don’t have full recognition of its status as a domain. We don’t know what things belong to that domain and what do not. We do not know what stories are unique to that domain and which are not. We do not know how language invokes stories in that domain that are not invoked in other domains. We do not recognize which concepts, ideas, and principles belong uniquely to that domain.

It is like knowing the city you were born and brought up in but having no idea which things, customs, laws, and people are common to all cities and which are unique to your own. If someone from another city asks you what is cool or unique or interesting or important about your city, you don’t know how to answer them because you have no idea what makes your city different from theirs.

Domain awareness means not only knowing the subject matter of your domain well, but also understanding your domain as a domain and its place in the universe. It is only in a state of domain awareness that you act as a useful and reliable tour guide to your domain.

Domain awareness is the antidote to the curse of knowledge.

Domain awareness is the thing that sets the great explainers, teachers, and writers apart from the rest of us.

Notes from the road from ignorance to knowledge are of undoubted benefit in forming a domain awareness, though they are far from constituting the whole of it. Our particular journey is from our own ignorance, which may not be the same as another’s ignorance. And even if it is, we may take a different route from others. Domain awareness requires a more comprehensive view of what makes the domain distinct.

Domain awareness is by no means an easy state to achieve, and much documentation must necessarily be written by people who have not achieved it. But it we want to identify the space where the best documentation gets written, it is domain awareness.

What is an “Expert Writer”?

“Hire Expert Writers,” Says Google

That is the title of a post from M2Bespoke about Google’s emphasis on returning reputable content. What is an “expert writer” in this context?

Many of those who have commented on it and passed it around take it to mean expertise in writing. That seems to be the interpretation that the author of the article is making as well:

There’s no doubt you’re experts in your industry, but do you have professional writers within your business to convey that expertise? Google says: if not, why not?

The search engine giant, who we all quite rightly pander to, has recently suggested that businesses need to hire expert writers in order to add a true level of authority to their content.

The way “professional writers” in the first paragraph elides into “expert writers” in the second suggests that the expertise that is sought is expertise in writing.

Yet as we read on, it becomes abundantly clear that what Google means is writers who are experts in their subject matter.

  • Complex medical advice should only be given by people or organisations that possess appropriate accreditation. It should, likewise, be written in a professional style and will need to be reviewed, updated, and edited regularly in order to ensure that it remains current and authoritative.
  • Complex financial advice, tax advice, or legal advice should be written by expert writers and will need to be updated regularly.
  • Important advice pages that may affect a person’s finances or well-being (this includes investment pages, home remodelling pages, and parenting pages) needs to be written by an “expert” source.
  • Hobby pages on topics like hockey, horseback riding, or photography, require expert writers.
  • read more

    Why does XML suck?

    XML sucks. Don’t get me wrong. All kinds of really valuable and important systems use XML to perform vital functions. But performing a vital function does not keep something from sucking. Lots of people think Windows sucks, but it performs a vital function, and lots of people use it because of that. In fact, performing a vital function is what keeps sucky things around. If they perform a vital function, they are hard to get rid of, despite the fact that they suck.

    Not that that prevents people from trying to work around them.

    Scott Able recently tweeted

    If we have markup, why do we need markdown?

    Markdown has been making major strides recently, particularly in the Web and developer communities. What does it have that XML doesn’t
    have? Simple: It’s easy to write.

    XML sucks for writing. Lets look at why, and how it came to be that way.

    XML is verbose

    First and most obviously, XML is verbose. If you write in raw XML you are constantly having to type opening and closing tags, and even if your editor helps you, you still have to think about tags all the time, even when just typing ordinary text structures like paragraphs and lists.

    And when you read, all of those tags get in the way of easily scanning or reading the text. Of course, the people you are writing for are not expected to read the raw XML, but as a writer, you have to read what you wrote.

    Of course, you could use a specialized XML editor that hides the tags, but that is another tool to learn and use and add to your workflow, and that sucks. Plus, they don’t completely solve the problem, as we shall see.

    Markdown is much less verbose. You can type a markdown document with not much more effort than typing plain text, and you can read it easily in source form.

    But there are other less obvious, but ultimately more vexing problems with XML.

    XML makes whitespace meaningless

    How do you indicate the structure of a document in print or on screen? Partly you do it with font choices and the like, but first and foremost, you do it with whitespace. Whitespace naturally and visually delineates the parts of a document. One paragraph is separated from another by whitespace.

    Markdown uses whitespace to delineate structure just the way a normal document does.

    XML? Not so much.

    In fact, in XML, most whitespace is simply discarded. You have to make special provisions to keep significant whitespace in things like code samples. To create a paragraph, you actually have to create an element (element <p> in some languages, <para> in others). We may be so used to this now we hardly think about it, but really, why the overhead when we could just hit return?

    In ordinary printed text, we use indentation to indicate a code sample or a quotation. In markdown, you do the same. In XML? Nope. More elements.

    This failure to use whitespace to mean what whitespace means in ordinary documents is a major contributor to the verbosity of XML markup. It is why we need so many elements for ordinary text structures and why we need end tags for everything.

    Why does XML ignore whitespace? Well, XML is a descendant of SGML. SGML stands for Standard Generalized Markup Language. The Generalized part means that it was intended for describing all kinds of markup for all kinds of purposes. That includes markup for things that might not have paragraphs or code samples or quotations. That means that whitespace could not mean anything specific in SGML’s “reference concrete syntax” — its default way of writing tags and attributes.

    However, SGML has several facilities that you could use to make whitespace and other characters mean something specific in a particular tagging language. Using these features, you could make a markup language that looked like Markdown and still parsed as an SGML document. In other words, in SGML, you could create a markup language that was easy to write. (Admittedly, these features were so fiendishly difficult to use that they had no chance of catching on.)

    XML did away with all these features. XML discarded all the things in SGML that made it possible to create markup you could actually read or write.

    Why? Because that was not what XML was designed for. XML was designed as a data transport layer for the Web. It was supposed to replace HTML and perform the function now performed by JSON. It was for machines to talk to machines, not for writers to write in. Writers were to write either in SGML or in WYSIWYG editors.

    So, XML ended up with no way to make whitespace meaningful. Which sucks, because in actual writing, whitespace is the basic building block of structure. Hitting return to create a new paragraph is an ingrained behavior in all writers, and XML breaks it. That sucks.

    XML has no semantics

    The reason that whitespace is meaningless in XML is actually far broader than just whitespace. XML markup has no semantics. That is, nothing in XML syntax itself has any meaning relative to the content or data it is marking up. It only has meaning in terms of XML’s own abstract data model of elements and attributes. It is entirely up to each specific XML tagging language to define what its elements and attributes mean. XML does not predefine anything for them.

    This is deliberate. XML was designed to be semantic-free, and for good reason. XML is what we call a meta-language. It is a language for describing other languages. Thus XHTML, DITA, DocBook, RDFa, RAML, SVG, XSLT, WSDL, XProc, S1000D, and BeerXML, along with all languages in this list on Wikipedia, and thousands more, are all markup languages with specific individual semantics, all of which are defined in XML. If any part of the XML syntax itself had inherent semantics, all those languages would have to share them, even if it were not appropriate for them. So XML is semantic free.

    But that means that you have to specify absolutely all of your semantics yourself by defining elements and attributes for everything. This is laborious, and tends to produce quite verbose data formats. The design goals section of the XML specification actually states: “Terseness in XML markup is of minimal importance.”

    For any application for which terseness is a useful property, this sucks. Human readable and writable markup is one of those applications.

    The lack of semantics in XML itself also creates a processing overhead. You have to parse the XML syntax first to pull out the elements of the specific tagging language and then run separate application code to interpret the semantics of that language. Along with its lack of terseness, this is what led to XML being rejected in favor of JSON by many web developers. JSON is “Java Script Object Notation”. It has the inherent semantics of Java Script objects right in its syntax, which means it is trivial to parse into memory and access directly with application code.

    Being semantic free is an important property of XML in its quest to be highly general. But it makes it suck for things like
    writing documents or swapping data between web servers and Java Script programs.

    XML hides structure

    Of course, if you have a graphical XML editor, you get back the ability to hit enter for a new paragraph. At least, sort of.

    It’s really not that simple. Since XML has no semantics, there is no way for the editor to know that Enter means paragraph, or even which tag means paragraph. It can know this for specific well known languages like Docbook, of course. But even then, there are problems.

    When the writer hits enter, do they mean “end this paragraph” or do they mean “start a new paragraph”. Typically, they mean both. But suppose there are other elements allowed inside a paragraph, like a list? Maybe the writer wants to create a list that is logically inside the current paragraph. It will still be whitespace separated in the output, of course, but if it is logically inside the paragraph, then we can’t assume Enter means “end this paragraph”. It may mean “start a list inside this paragraph”.

    And because there are a number of elements that could come after a paragraph, beside a new paragraph, we can’t assume that Enter means “start a new paragraph” either.

    Which means that when you hit Enter, the editor has to ask what you want each time. In some editors, therefore, hitting Enter brings up a list of choices. Usually there is a default choice, which is usually a new paragraph, which you can choose by hitting Enter again. That’s not so bad. But then again you can’t always hit enter twice without looking because sometimes the thing you want next isn’t the default. You have to stop typing and look. And that sucks.

    It gets worse when you try to edit something. Let’s suppose you want to insert something between a list item at the end of
    one section and the title of the next section of a document.

    On your screen you will see white space between the list item and the section title. In that white space there are the starts and ends of several elements.

    • The end of the paragraphs inside the list item
    • The end of the list item
    • The end of the list
    • The end of the paragraph that contains the list (if it is inside a paragraph).
    • The end of the section
    • The start of the new section
    • The start of the title of the new section

    But these starts and ends of structures are all invisible to you because they are not part of the WYSIWYG display. Depending on what element you want to insert, you have to get your cursor into the right bit of on-screen whitespace that represents the element you want to be in.

    To add an item to the list, for instance, you need to get your cursor inside the list. To add a new paragraph to the section, you need to get your cursor after the end of the paragraph and before the end of the section. But you can’t see any of these locations. All you can see is a block of whitespace. The editor will have aids to help you find the right place, of course, but it is all terribly cumbersome and time wasting for what should be an operation you perform virtually unconsciously.

    This is far from being the most difficult instance of this, and the result is that most writers writing in XML regularly switch back and forth between the graphical view and the raw tags view of the document they are working on, in order to find the place they need to be to make the edits they want. And that sucks.

    Cutting and pasting content in the graphical view of an XML editor can be even more of a nightmare. You can’t see exactly which set of tags you have picked up, so you can’t tell what is legal to paste in what location, or what damage you might be doing to the current structure by removing the chunk you cut. Again, the editor will help all it can to repair the damage, but, again, what should be a simple and intuitive operation becomes an exercise in negotiation and troubleshooting.

    And this is just the problem of dealing with simple text structures. What if you have significant semantic markup in your document? These elements and attributes are not visible in the graphical view because they are not intended to be visible in the published document, but to inform downstream processes. Particularly maddening are XML attributes, which are use for information that is intended to be “out-of-band”, that is, not presented to the reader. Editing and entering attributes in a graphical view invariably involves multiple keystrokes invoking dialog boxes, choices from lists, and typing into dialog fields. It sucks.

    In short, you can’t just sit at the keyboard and type your document, and that sucks, no matter how good your XML editor may be. There are some very good XML editors, and you are likely to need one if you have to write a lot of XML, but none of them can take all the suck out of XML itself.

    In Markdown, by contrast, you can just sit down and type your document.

    To create structure, you need to see structure

    The key thing here is that to create structure, you have to be able to see the structure. We have all used those free-form HTML editors in blogging platforms and Web CMSs and we know that the HTML they produce is a horrendous unstructured mess.

    Using Markdown is a huge improvement because the author can see the structure and therefore won’t mess it up. And because Markdown uses whitespace to mean what it natively means, there are few end tags to worry about, and therefore to misplace, so it is physically impossible to make as much mess as you can with HTML tags.

    XML editors, while much stricter, still don’t let you see the structure, but instead of letting you make a mess, they continually scold you with obscure error messages about structure errors, which are hard to fix because you can’t see the structure. Or they simply prevent you from typing what you want to type until you get your cursor in the right bit of whitespace. (Actually, how much mess you can make vs. how much scolding you get is more a function of the specific language than then editor. But it is always one thing or the other.)

    The alternative is to look at the raw XML tags, but while the structure is technically visible in raw XML view, it is often impenetrable because of the verbosity of the tags, and because your most basic structural clue — whitespace — is either not used at all or is used to show the hierarchy of the tags, not the significant structures of the document.

    In short, XML hides document structure no matter how you view it, and that really sucks.

    The price for generality is suckiness

    This is always the problem with generality. The things you have to do to a system or format to make it more general inevitably make it more complex and more verbose. It can’t incorporate all the shortcuts that would seem natural in a system built for a single purpose because they would be inappropriate, awkward, or limiting for other purposes. If it attempts to provide a mechanism for building your own shortcuts (as SGML did) then it becomes even more complicated.

    Inevitably, people will create special purpose alternatives for individual applications (like JSON or Markdown) or attempt to simplify the general system (like XML did to SGML).

    The upside of the more general system, at least if it has any traction, is that there are tools and people who support it. Sometimes the presence of these resources makes up for the costs of its verbosity and complexity.

    In other cases, however, the level of support does not make up for the suckiness. Then new formats are proposed and developed and support systems develop around them, as they have with JSON and Markdown.

    Elliot Kimber has an excellent presentation called Why is DITA so Hard. DITA is hard, he acknowledges, but he maintains it is not DITA’s fault. DITA is hard because the problem is hard. The presentation lays out the full extent of the configuration management and publishing problems associated with technical communication (and large scale corporate publishing more generally) and shows how DITA seeks to be a general solution to those difficult problems, which makes DITA itself difficult.

    The thing is, of course, that no one organization actually has the complete technical communication problem, which is the union of all the problems that individual organizations face. DITA is hard because the entire problem is hard. But no one has the entire problem. Many organizations don’t have anything like the whole problem. So why do they need a tool that is as hard as the whole problem?

    Part of the answer is that if they have a significant part of the whole problem, it is less expensive to adopt a tool that solves the whole problem — even if it is more difficult to use — because of the support base, the tools, and the accumulated knowledge. (This depends, of course, on whether there are other tools available that are closer to the subset of the problem that they have.)

    Partitioning the problem space

    There is another approach to solving hard problems, other than building one tool to solve them all, and that is to partition the problem space into smaller problems that are easier to solve, and which have solutions that are easier to use. That is what many organizations have done, and it is often the right economic choice to make.

    In fact, all organizations partition the problem of creating content to one extent or another. There is no organization that is going to create all of its content in DITA or in any form of XML. It would be cost prohibitive to do so, and people across the organization would rebel against the difficulty and complexity and the general suckiness of trying to do everyday communication tasks with these tools.

    The price of partitioning is fragmentation read more

    One Answer, Many Questions

    It is often appealing to think of technical communication as a process of answering user’s questions. The difficulty with this view is that one answer can have many questions. If you answer each of those questions, you would be providing substantially the same answer over and over again.

    This is very easy to see on StackOverflow, a question and answer site for programmers. Privileged user of StackOverflow can mark a question as a duplicate of another question. Here’s an example:

    A question marked duplicate on StackOverflow.

    The question here is “How to check if a variable is a dictionary in python”. This is a question that programmers are going to ask themselves many times. It is a specific instance of a more general question, which is, “how do you check if a variable is of a specific type in Python?”

    The programmer may know that their question is an instance of the more general question, or they may not. This depends on how much they know about types in programming languages generally. Even if they do know about type theory, however, they may not think to generalize their question (or to do a search for the more generalized question). Generalizing a question requires mental effort and a person struggling with this problem may not have a lot of additional mental energy to spare. Stress makes us dumb.

    Whether they realize it or not, the answer to this question is largely the same whether you want to find out if your variable is a dictionary, a tuple, an exception, or a number: you use either the type() function or the isinstance() function.

    Since these functions work somewhat differently, you will need to decide which to use. And this means that the answer to this question is substantially similar to the answer to another question: “[What are the d]ifferences between isinstance() and type() in Python[?]”

    And because of this, someone has marked the question about finding out if a variable is a dictionary as a duplicate of the question about the difference between isinstance() and type(). That question is shown in screenshot below:

    A question marked duplicate on StackOverflow.

    Now let’s be very clear about this. “How to check if a variable is a dictionary in python” and “[What are the d]ifferences between isinstance() and type() in Python” are not remotely the same question.

  • The only words they have in common are “in Python”.
  • One is asking how to do something; the other is asking about the difference between two features.
  • You would have to know the answer to the first question to know that the second question was in any way relevant to what you are trying to do.
  • A person asking the first question is not likely to think that the second question might contain the answer they are looking for. A person asking the second question is not likely to think that the first question might contain the answer they are looking for.
  • No search engine is likely to identify one as the answer to the other either, though the answer to “How to check if a variable is a dictionary in python” will at least contain references to type() and isinstance(), which might give it a clue.
  • read more