Flash Bashing
With the emergence of the powerful combination of HTML5, CSS3 and Javascript/jQuery as a browser-native way to produce animated and more complex interactive features for the web, many developers have been very eager to throw a particular baby called Flash out with the bath water – only to themselves engage in the same form of abuse of a new, preferred technology that they were once so critical of, when the name of that technology was Flash.
What developers are commenting on in these instances is typically Flash as it relates to web content publishing, and more specifically the Flash plugin as a rendering and delivery mechanism for that content. While most of this criticism is certainly valid, it represents a very narrow way to look at Flash, which really did not start as a web publishing tool, but as a sketching tool, and a vector-based animation tool, which is still where Flash is at its best, and where it is still very much relevant.
Flash is a design tool that allows a designer to build scalable and lean vector designs, ideal for a device-agnostic media landscape (SVGs anyone?). Flash offers both a spatial-, a layered-, a temporal state- and a behavior/object-oriented approach, with the canvas, timeline and its keyframes used to define both progressive and conditional changes to the design elements. In this, Flash allows for easy creation of library objects (way superior to Photoshop’s so-called smart objects), which enables the designer to create modular and adjustable design objects which scale very well into the creation of entire design systems.
Used right, Flash allows a designer to set up a proliferation of design objects with shared and nested library building blocks, which can be edited once, but where edits apply in multiple instances at once, while still allowing for some modification of each element in all individual instances where they occur (this, by the way, in many ways mirrors Sketch, a tool that is de-rigueur and more broadly used today). Flash also makes it easy to export all these objects with one command, in a variety of formats and resolutions, as a virtually unlimited series of bitmaps – very useful when for instance producing banner ads in many different versions.
All this makes Flash a very powerful, and truly dynamic graphics production tool with, in my mind, a more pragmatic and flexible approach than for instance Photoshop, which locks things into a more static and restrictive layer paradigm that is still burdened by its photo retouching origins. In fact, Flash can with a little extra work be used to mimic the functions of, and deliver some of the same benefits as, a dynamic ad serving tool, making the entire production process very nimble and efficient.
Furthermore, when developers scoff at Flash, and claim that HTML5 can replace it for animation purposes, that is not strictly true, and reveals a basic lack of understanding of Flash and its capabilities, as well as an over simplified view of animation as a practice.
For animation purposes, HTML5 is (at most) an animation encoding method; it is obviously not an animation tool per se. Flash, on the other hand, offers an entire animation environment in which you can do much more than just move shapes and text around, and create simple transition effects. Character animation, for one, is still something where Flash is very useful, since it integrates well with other production tools (such as Photoshop, Fireworks, or Illustrator), and producing animated graphics is still vastly more efficient and quick in Flash than anything related to, and restricted by, front-end presentation code.
There is absolutely nothing saying that Flash must be used only to output SWF files – the output and application options are really much broader than that, and are not even necessarily restricted to just graphics. Flash also offers a quick, simple way of integrating video and audio with any other visual and/or interactive material.
One must also remember that Actionscript is (still) a pretty powerful coding language for interactivity. I would argue that things like prototyping, or building apps or games for instance, are still much easier in Flash, than trying to turn a web page into an app, and coaxing the browser to render it in real-time, while simultaneously calculating outcomes and maintaining state of complex sequences of user interactions. Flash also frees you from the inconvenience of browser incompatibilities, and other browser-related limitations. That alone often makes it worth considering.
So, when rejecting one technology for another, it is still important to ask oneself what the technology is going to be used for. There are still lots of good uses for Flash, but to publish animated and/or interactive web content to be embedded on web pages using a plug-in – intros, content effects, interactive features and page behaviors etc – that was never its core strength to begin with, and never where it was best utilized.
We should perhaps at this point stop and ask ourselves if the current explosion of gimmicky HTML5 widgets doesn’t in fact in many respects mirror the early, somewhat annoying over-utilization of Flash in (mostly) non-meaningful ways.There is really no reason to favor poor usage of one tool over equally poor usage of another.
Once the dust settles, smart UX designers out there will know when to use certain tools, and when to continue searching through their toolbox. What ultimately matters are not the tools themselves, but what you do with them.
It’s really not any more complicated than that.

The main principle of typography in User Interface design governs how text in UI elements is mainly functional (as opposed to communicative): UI text serves to explain the purpose of navigation elements, and guides interaction.
Texts in buttons are essentially labels, and labels have specific legibility requirements: the strokes need to be uniform and thick, the character width should preferably be rather narrow (to be more economical in terms of space), and the X-height should be tall, to make the text larger, since type size is by far the most critical requirement for legibility in UI design. This is important given that UI elements need to function in many different sizes, which is especially true in responsive design, where pages size up and down dynamically. Also, serifs tend to create kerning issues, which means characters need to be separated and spaced more liberally, so as to not have characters bump up against each other and create confusion about individual character shapes. That means that serif fonts are inherently less suitable for UI elements.
As for UI typography as it relates to branding, human computer interaction is a universal field – it is not tied to a specific corporate identity. What we recognize as a clickable element, such as a button, and therefore understand how to interact with, is different from what a brand and a CID dictates in terms of recognizability, and the principles of visual persuasion associated with branding. If you think about it, corporations typically don’t have custom designed door handles in their offices, and that is because handles are functional – they are more important to allow people to open doors than they are to establish a corporate identity. The same thing goes for UI elements.
Ultimately, this comes down to how we need our clients to trust that we keep their best interests in mind, while leveraging best practices and maximizing the benefits of our professional experience. The best person to make the distinction between branded elements and functional elements is probably always going to be a designer.
This article explains the issue very well: http://typecast.com/blog/type-on-screen-5-faces-for-ui-design. As you’ll notice, all the recommended typefaces are sans-serifs, for reasons explained above.