Coherence Labs

Year: 2013

  • 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!

  • TypeMetal 1.1.3

    XHTML: Is it a kind of HTML, or a kind of XML?

    TypeMetal 1.1.3 recognizes this for the trick question that it is — respecting XHTML as both a floor wax and a delicious dessert topping!

    With this update, TypeMetal allows for any XHTML file to have .xhtml, .xhtm, .xht, or even .xml as its filename extension, in addition to the extensions already supported for ordinary HTML files: .html, .htm, .shtml, and .shtm. (An .xml file must contain XHTML for TypeMetal to be able to open and edit it.) This should help users working with other tools and workflows that insist on particular extensions for XHTML files.

    As usual, the TypeMetal Demo build has been updated to match, and there’s a minor update to the online User Guide that mentions the newly supported filename extensions.

    This fix comes in response to a user request, so please keep the bug reports and suggestions coming! Your feedback is always welcome and appreciated — on Twitter, on the TypeMetal Support Forum, or emailed directly if you prefer, to “support” at coherencelabs.com.

    We’ve been working nonstop on TypeMetal improvements, many of which will be part of a major free update due coming months. Stay tuned to our News and Twitter feeds for the latest — and thank you for your support!

  • TypeMetal 1.1.2

    …is now available via the usual App Store Software Update mechanism! This version fixes some needless annoyances, where the editing area sometimes wouldn’t show a newly dropped or inserted image, or wouldn’t update to reflect a stylesheet change, or the URL completion window wouldn’t size itself wide enough to show the URLs it presented in their entirety.

    TypeMetal 1.1.2 also adds handy new Command+Option+arrow keyboard shortcuts that you can use to hop from node to node in the document tree:

    Selecting Content in Normal Mode
    Keystroke Command
    ⌘⌥↑ or ⌘⌥G Grow Selection (to Enclosing Element)
    ⌘⌥↓ Select first child node
    ⌘⌥← Select previous sibling node in current element
    ⌘⌥→ Select next sibling node in current element

    These keystrokes are especially useful for hopping TypeMetal’s Attribute Editor to adjacent elements, without having to close and reopen it:

    In the Attribute Editor
    Keystroke Command
    ⌘⌥↑ Jump to parent element
    ⌘⌥← Jump to previous sibling element
    ⌘⌥→ Jump to next sibling element
    ⌘⌥↓ Jump to first child element

    TypeMetal 1.1.2 also fixes the snippet editor’s “shorthand example” tooltip sticking around indefinitely, as well as the failure to display snippet body content when reopening the snippet editor for an already-loaded snippet set. And, if you’ve run into the “Unreasonable Permission Request” sheet that used to spell doom for the ability to open and edit certain HTML files, you’ll be glad to know it’s entirely gone in TypeMetal 1.1.2! The revised Help page on “Granting TypeMetal File System Permissions” explains the new authorization issues UI, which never prevents you from opening and editing an HTML file, and offers the ability to balance Sandbox security concerns with whatever level of file system access you feel comfortable granting. If TypeMetal finds the need to exercise caution in requesting resource directory permissions when opening an HTML file, you’ll see a yellow diamond icon in the newly opened window’s title bar:

    You’re free to ignore that yellow diamond, and edit the HTML file as you wish, with the only consequence that some referenced images might show up as broken images, or referenced style sheets might not be visibly applied, while you’re doing your editing. The failure to load certain resources only affects what you see while you’re editing; it doesn’t affect the HTML that TypeMetal produces. You can click the yellow diamond icon if you choose to, and TypeMetal will show you the list of problematic resource folders that triggered the warning, and give you the opportunity to grant access to those folders if you wish.

    Two more things to note: TypeMetal is both Retina-ready and ready for OS X Mavericks. We’re continuing to test on the latest developer builds, watching for potential problems, but so far all looks good for a smooth transition to the latest and greatest version of OS X!

    As always, we’ve updated the TypeMetal User Guide and the TypeMetal Demo build, and posted the release notes. More great improvments are already in the works for future versions of TypeMetal! Stay tuned to our Twitter account and RSS feed for the latest news and tips, and let us know about any issues you run into or things you’d like to see, in the TypeMetal Support Forum (or, if you prefer, email “support” at coherencelabs.com).

    Thanks again to all our users! Your support makes all of this possible, and we look forward to bringing you still more handy, agile ways to write and edit your HTML content!

  • TypeMetal 1.1.1

    …fixes some bugs to make Find and Replace work as they should. This latest TypeMetal version is now live on the App Store, and I’ve updated the free TypeMetal Demo build to match. (The release notes for the latest version of TypeMetal are always available to view here, by the way.)

    I’m hard at work on a number of other improvements that will appear in future updates, with user-reported issues getting top priority — so if you don’t see a reported problem that’s troubling you addressed in this build, please rest assured that help will be on the way shortly. Thanks again to TypeMetal’s amazing and growing user base for your support and feedback. Please continue bringing your questions and concerns to the TypeMetal Support Forum, where I’m usually able to notice and respond to posts within hours if not minutes (during my generally long waking hours, at least!). :-)

  • TypeMetal and Semantic Markup

    Posted yesterday and well worth contemplating if you write HTML: a Smashing Magazine article on HTML/CSS philosophy. Author Heydon Pickering briefly touches on one of the main issues that drove me to develop TypeMetal and make snippets-as-first-class-completions a key feature — the difficulty of remembering and consistently applying one’s own CSS “class” names — even as he proposes a strongly “class”-averse approach to markup and styling. Pickering’s objection to use or overuse of class attributes is a philosophical one, that’s well worth giving some thought to. My interest has been in solving the practical problem of how one can apply class-element pairings more easily and consistently, in cases where they’re an appropriate tool for the job.

    I find a lot to recommend in Pickering’s discussion, actually, even though I take a less strict approach to coinage and use of “class” attributes. I agree substantially with the general premise — it makes a great deal of sense to leverage HTML’s existing semantics, in preference to reinventing the wheel, wherever a suitable element exists for a given purpose. (Among other significant benefits, doing so tends to make your content more intelligible to screen readers.) And Pickering’s article does a great job showing just how far one can get, styling-wise, using CSS descendant and attribute selectors alone. I tend to favor that approach whenever it seems reasonable, but there are cases where I think it’s useful and appropriate to leverage the extensibility that HTML provides for, by developing and applying a consistent vocabulary of “class” names. The best approach to doing so, in fact, incorporates a respect for appropriate usage of HTML’s element set — employing “class” identifiers to add further semantic specificity to an appropriately chosen element that’s already in the right neighborhood of meaning. This means avoiding the generic <span> and <div> whenever possible, in favor of more meaning-infused elements such as <code>, <kbd>, <article>, and <section> (to name just a few). While I think the lofty goal of class-free or nearly-class-free markup is in great measure worth striving for, I also think there are inevitably places where it’s useful to be able to express concepts that HTML’s standard vocabulary doesn’t, and can’t be expected to, intrinsically provide for.

    In TypeMetal’s User Guide, for example, I wanted a convention for marking up the names of menu items — in large part, so that I could style them all consistently, and later restyle them at will, but also because being able to find or index menu item references might come in handy someday. HTML’s <menuitem> element being unsuitable, despite a name that might seem to suggest otherwise (<menuitem> is for commands that a page visitor can choose), I went with <strong> (to make menu items likely to stand out from surrounding text, even if one views a User Guide page without its accompanying stylesheet), annotated with a “class” attribute of “menuitem”.

    When you apply class-based styling like this, it’s a given that the class names you’ve chosen, while meaningful to you, are unlikely to mean much at all to Web crawlers and other software that isn’t versed in your particular custom styling vocabulary. That’s part of the tradeoff. My use of <strong class=“menuitem”> is an imperfect choice, but preferable, I think, to not annotating menu item names at all.

    There are many such cases one can readily think of, especially when you get into writing about specialized areas of knowledge. Each has its own objects of interest, that can be useful to identify with formal markup. When you have a writing tool that helps you develop and remember your styling vocabulary, and apply it easily and consistently across a body of work, the potential to do such things becomes much more feasible to realize in actual practice. That’s been a substantial part of my goal in developing TypeMetal, and an area where it’s become tremendously helpful to me. I’m excited to finally have it out in the world, where it can help other HTML authors to achieve the same productivity boost.

    I’d love to hear about cases where people find TypeMetal’s approach helpful, and how it might be improved to provide even more convenience and agility. Please feel welcome to tweet @CoherenceLabs, email “support” at coherencelabs.com, or post in the TypeMetal Support Forum! — Thanks!