Time for an HTML revolution

When I worked in the studio and dark room of a local newspaper, one of my first tasks was copy mark-up. This was before the days of WYSIWYG (What You See Is What You Get), so you had to quickly conceive a layout, either in your head or a rough sketch, deciding where the text and graphics would go. Then you would have to cast-off (character count) and mark up the copy with instructions for the typesetters to follow, including the font, the point size, the leading, justification, column widths and so on. It made sense and saved space to write this in the format the phototypesetting system required, which looked very much like a line of HTML (HyperText Markup Language).

The Linotype CRTronic

The Linotype CRTronic

Although I went on to use more sophisticated systems, they were still command-driven, so it was a revelation to run Aldus Pagemaker for the first time — on an Apple Macintosh in 1986. This was the birth of desktop publishing. For the first time, we could see if our designs would work before we committed them to expensive materials and wasted too much time. No longer did we have to type strings of commands. The new graphical user interface was user-friendly and prevented our worst mistakes. No longer did we produce reams of 72-point text when we intended it to be 12-point. Gone were the days of casting-off copy: why waste time calculating how many pages your text would make when you could easily run it into a template and experiment?

It seems to me that the way we produce HTML code today is very similar to the state of typesetting immediately before the advent of desktop publishing. Admittedly, the units of measurement are now pixels instead of points, but they are still 1/72nd of an inch. Perhaps I am lazy, but I much prefer the desktop environment where we create documents in InDesign, Quark Xpress and MSWord. No longer do we have to remember all the coding or understand what takes place behind the scenes to render our design on screen.

One welcome innovation for reluctant HTML-coders has been the arrival of Cascading Style Sheets (CSS). These make it unnecessary to tediously specify every last detail repeatedly in the HTML, which may simply invoke a style detailed separately in the CSS document. Unfortunately, this brings a whole new coding language into play, requiring any serious web designer to be proficient in both, so it’s not a solution in itself.

Whilst recently experimenting with various applications to produce user interface design prototypes, I came across Maqetta from the Dojo Foundation. It is “an open source project that provides WYSIWYG visual authoring of HTML5 user interfaces and runs in the browser without additional plugins or downloads”. The idea is that a dummy like me can put together a decent-looking prototype, which a proper coder could then use as the basis for a working site. It is designed so that users could install their own CSS and widgets (components), so it is already quite flexible and tunable.

Maqetta puts me in mind of the first time I used Pagemaker. It’s not as slick, intuitive or functional as the applications that went on to dominate desktop publishing (InDesign and Quark Xpress), but it’s a step in the right direction.

App Inventor

App Inventor

In a similar vein, Android App Inventor offers an ingenious way for developers to build apps without using code. You drag and drop components from palettes and edit their properties to assemble the screens, then launch the Java ‘Blocks Editor’. This offers a library of blocks of code, which you drag and drop on an assembly area where they may be combined like jigsaw pieces to program the functionality. To test your handiwork, you may either plug-in your own smartphone, or launch the in-built emulator.

App Inventor's Blocks Editor

App Inventor’s Blocks Editor

This free application was launched by Google (but is now managed by MIT) to encourage developers to produce apps for Android and I must say that it is very impressive. I took the Udemy course ‘Android Apps in 1 Hour: No Coding Required’, but be warned: it includes 227 short video lectures and, although there is no code to master, such sophisticated functionality still presents a stiff challenge to the novice. Unfortunately, it is not possible to export Java script for use elsewhere.

Apple’s Xcode looks as slick as you would expect, but still requires some object-oriented programming, so the masters of the graphic user interface have some catching-up to do.

Who cares?

The reason I am so keen for HTML programming to be more widely accessible, rather than remaining the preserve of the geek, is not so much that I have got anything against geeks, it’s just that I hate anything to be unnecessarily complicated. Android App Inventor shows that it ought to be possible. The other point is that it is so inefficient to create three different versions of content to suit three platforms: websites, Android and Apple. I am sure, if my wish comes true, there will be concerns from traditional coders about falling standards and inelegant coding, but they should carry no more weight than they did when typesetters made similar arguments twenty-five years ago.

When I entered the publishing industry, I delighted in the mystique surrounding our arcane terminology, which acted as a barrier to new entrants. Desktop publishing democratised the industry and the same revolution needs to happen in the online environment, the sooner the better.

This entry was posted in Media, Personal and tagged , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s