Why markup languages are useful for UI definition

- [Instructor] Markup languages are consuming the world. They are the bedrock of the modern publishing industry, and are pervasive in software development. And they are common place as a UI definition language in many modern day UI frameworks. HTML and XML are the most prevalent markup languages. HTML is often used to describe online documents. The HTML elements indicate the semantic meaning of the embedded content. Therefore both humans and computers can read this HTML document and know what the different parts mean. The body tag on Line Three indicates the main body of the document. This is what the browser shows in the browser window. The H1 element on Line Six declares that this text is a header, so the human reader knows that it's an important headline text. And the browser and other user agents know to render the text with a header look. The p tag on Line Seven defines a paragraph, which tells the human editor that this is the start of a new idea encapsulated into a paragraph. And the browser knows to format this text to start on a new line. Similarly, each of the other elements in this example have specific semantic meaning. I don't have to tell you much about the img element on Line 11. You can probably determine that it's used to define an image within the document, and the src attribute indicates the image location. HTML is very popular. Not only is it the basis of document markup, which is its original purpose. But it's also considered a fundamental part of creating web applications and defining the user interface for those web applications. HTML is constrained to a pre-defined set of elements and attributes. Meaning, you can't define your own elements and have them mean anything to the browser. Well, that's not entirely true. HTML5 has the new data attribute. But I'll ignore that for now. XML is a markup language commonly used to describe data. Unlike HTML, it is extensible. In fact, that's part of the name. Extensible Markup Language. I can define any element or attribute I want in an XML schema file. Then create an XML document that references my custom schema. Now I can use my custom elements in the data document, like the one shown on the left. I've got elements that make sense for my company data. This is information about our truck fleet. So there's a fleet element on Line Four. A truck element on Line Five. And color, year, make and license elements too. And there's attributes. See the division attribute on Line Five, and the warranty attribute on Line 10. It didn't take long after XML appeared for enterprising developers to consider writing an XML schema that defines UI elements for GUI frameworks. I know I did. I wrote an XML schema for a UI automation engine back in 2001. Here's what one might look like. It's the example on the right side. In this file, the elements define the UI parts. The screen on Line Four. A layout helper on Line Five. And you can see the alignment attribute on that same line. That indicates how the layout widget should align the content. Then there are the other UI specific elements. Text, image, button, divider and more. As you look through the attributes, it's a simple act to determine what each attribute does. For example, the column count and row count properties tell the grid how many rows and columns to render. This is not a real XML implementation. I fabricated it for the demonstration. But, there are real world examples. Here's one. This is an example of Android XML used in Android apps to define the UI. Line Four defines a linear layout that defines a single child element, the button. On Line 10 is the Android colon ID attribute. A way to grant each UI element a unique identifier. Line 13 uses the Android colon text attribute to specify the text to show on the button. Don't worry about the details. This is not an Android course. This shows one way to use XML to define UI. Here's another. This is from the Apple iOS world. This is a Storyboard XML file. Storyboards in iOS define the app views and transitions between views. As you look through this document, you'll see element names that make sense for the iOS framework. Scenes, view controllers and layout guides are some of the ones included in this example. There are some benefits from using XML for UI definition. For one, the XML is stored in a text file, and it's human readable. Meaning that the average developer or designer can open the file and understand the general layout of the UI by reading the XML. Plus, XML by its very nature is extensible. That means that anyone can create an XML schema and designate custom elements and attributes. So Android can define a button element, then read the XML file, and convert the element into the runtime equivalent of the button. XML provides better separation of concerns. The UI's defined in XML. The interaction code is defined elsewhere, usually in a code file. Another advantage is that XML is easy to generate from tools. For example, in iOS development. I can use the Xcode tool, and use a visual designer to define my storyboard. As I make changes in the designer, the XML is updated to reflect the current values from the designer screen. Here's a visual example. The separations of concerns comes from having the UI definition in the XML file, and the interaction code in a separate file. I open the XML file in a simple text editor, and type in the XML markup. Later, I can open the same XML file in a developer specific tool. It might be the Visual Studio IDE when working with Microsoft XAML files. It could be the Apple Xcode IDE when working with iOS Storyboards. The IDE has tools that understand the XML schema. These editors and designer windows read that XML and allow me to work on the XML in a richer environment, compared to a plain text editor. When I use the IDE designer and make changes, they are turned into the correct XML and inserted into the XML file. At some point, I'll turn the UI over to our design team, so they can polish the UI. They'll open the XML file in a designer specific tool, and make their changes. The designer tool is optimized for the way designers work. It has windows and menu choices that make sense for their workflow. But when the changes are saved to the UI, the result is still an XML file. The changes are inserted into the same file I worked on in the developer IDE. Throughout the process, none of the change affected the code file. To be clear, a developer can modify the code file in the developer IDE. But the designer wouldn't. And that makes both sides happy. If you've ever worked in a team situation where the code and UI definitions are in the same file, you know that unintended changes can creep into the common file. In conclusion, XML provides a popular way to define data in a text file. The XML schemas are flexible. So you'll see a vast range of data structures kept in XML files. UI frameworks are not shy about using XML files to store UI definitions. By using XML for UI definitions, you get a clean separation of concerns. And tool makers can build interactive designer tools that read and write from the UI XML file. Overall, XML is a sensible choice for this task. So it won't comes as a surprise to learn that Microsoft has their own implementation. And that's what the rest of this course is about.