Tag: Preview

  • Treating Preview as “the” View, and HTML as a File Format

    An interesting theme has recurred in a couple of recent reviews of TypeMetal: thinking of TypeMetal’s content editing area as a “preview”, and the corresponding HTML markup syntax displayed by its Source Loupe as the implicitly the more real, authentic, or authoritative representation. This should be unsurprising, given the primary way we’ve become accustomed to producing HTML: writing HTML markup by hand in one view, while being shown a “preview” of the rendered page in another. The HTML markup view is conventionally where all edits must be performed. The preview is understood to be a browser-like, output-only display of the rendered page, whose content can only be changed by editing the corresponding HTML markup in the other view.

    TypeMetal’s approach can take a little getting used to, precisely because it inverts this conventional relationship between editing and preview areas. In TypeMetal, the fully rendered page is the editable representation. You drop your insertion point into it and simply start writing. User interface features such as the Path Bar, Block Mode, and Attribute Editor help you to see, grasp, and manipulate the semi-invisible HTML elements that you apply to annotate your text, making this “WYSIWYG” (“What You See Is What You Get”) editing interface feasible.

    Editing an HTML Page Using TypeMetal

    If you think of writing with TypeMetal as akin to using a word processing app or similar document editor, this approach feels completely straightforward and intuitive. It’s only in contrast to the ways we’re accustomed to producing HTML that it seems at all surprising. In the respects that matter for most content production, a rendered page is in truth no less authoritative or complete a representation than the corresponding HTML markup — it can even be viewed as more so, given that the rendered page, not its raw markup, is what you intend your site visitors to see.

    Considering other apps and document types clarifies this stark contrast in ways of working: When using Pages or Word to do some writing, you probably don’t give any thought to the effect your writing will produce in the bits and bytes of the document file that results. What you see in the app window and on the printed page are what matters to you. They’re the end objective. Similarly, if you draw something in OmniGraffle, which representation of that document do you think of as more relevant: the dumped contents of the document file?

    ...
    <dict>
      <key>Bounds</key>
      <string>{{40.999997456867277, 216.37498982747411}, {247, 284.58334350585938}}</string>
      <key>Class</key>
      <string>ShapedGraphic</string>
      <key>ID</key>
      <integer>145</integer>
      <key>Layer</key>
      <integer>4</integer>
      <key>Shape</key>
      <string>Rectangle</string>
      <key>Style</key>
      <dict>
        ...
      </dict>
    </dict>...

    or the rendered shapes?

    a drawing

    The point is unavoidably obvious in this case. So why do we think of HTML any differently?

    Partly because we can: HTML is essentially just a syntax for annotating plain-text content, that can be produced by anyone using a plain-text editor. By design, this fact helped catalyze the explosive growth of the Web: no specialized tools are needed to build a website. When the basis of your document format is plain text, it’s easier to think of file content as simply “the document”, rather than as a format for storing something more naturally or usefully thought of in more symbolic ways.

    The other aspect of this is that we simply haven’t invested much in creating tools to make the job of writing content for the Web easier. We’ve put up with a tedious but straightforward approach of largely hand-coding our HTML, and just accept it as an intrinsic part of the process. (Or, we forego direct writing of HTML and instead use a shorthand syntax such as Markdown to produce a desired HTML result.) Since HTML boils down to plain text, this is an entirely workable approach, but it leaves us with working environments that don’t do everything they could to make the process easier and more productive.

    TypeMetal’s development has been driven by a desire to find out what we can achieve when we invest seriously in developing tools for HTML content production. TypeMetal shifts the conversation back to thinking of the rendered page as the primary representation of our work product. Authoring of and interaction with what site visitors will see is more direct, in ways that are more than just skin-deep: the “DOM” tree of elements and text is TypeMetal’s primary representation of your document, and is the complete, authoritative model that every TypeMetal editing action operates on. TypeMetal applies your chosen HTML formatting preferences to produce HTML syntax from this tree — effectively relegating that HTML syntax to the role of a mere file format in which your documents are stored. Consequently, as with so many other kinds of documents for which first-class editing apps exist, the conceptual object model takes center stage, and the syntax becomes in some ways a mere detail of the way the objects are stored persistently — a serialization format for “sleeping” objects to be held in, until we’re ready to load and use them again.

    This emphasis on a symbolic content model yields substantial workflow benefits: no more need to mentally map between a presented “preview” and a separately presented document you’re editing, no more temptation to fiddle with the minutiae of markup formatting or need to ignore visually distracting markup syntax when you’re trying to focus on the text you’re writing and the ideas it conveys. Moreover, you gain the power of a writing tool that understands and can manipulate your content as an association of first-class objects, rather than as a continuous stream of character-level syntax. This foundation facilitates symbolic validation as you edit, agile operations on tables, lists, and headings, and the ability to drag-and-drop entire subtrees of content, and will underpin still more powerful editing capabilities as TypeMetal’s development continues to advance.

    The best way to see how easy and productive direct editing of rendered pages can be is to try TypeMetal, and we invite you to do just that using the free downloadable demo version. When you’re ready to make this adept new way of working part of your content production process, you can find the full version of TypeMetal exclusively on the Mac App Store.

    Take TypeMetal for a spin — we think you’ll wonder how you lived without it!