I recently completed a project where I was tasked with creating a mega menu but was also afforded time to focus on website accessibility. Sure, I knew of the value of HTML5 validation, image alt tags, and including a skip navigation button, but during my research this video inspired me to give up icon fonts and try to include ARIA roles in my code.
In keeping with this accessibility-conscious kick, I sought a mega menu navigation that supported ARIA roles. I ultimately came across Adobe’s mega menu from 2013. While I uncovered other JQuery mega menus, I still consider this one to be one of the best examples of a working mega menu that’s also accessible (see Adobe’s Github repo).
The object arguments for the accessibleMegaMenu() constructor are a bit excessive, but I’ve kept with Adobe’s pattern in an effort to make the code as approachable as possible. I added three major arguments:
navToggle – The id selector of the element triggering the mobile menu toggle
navId – the id selector of the navigation
mobileBreakpoint – The breakpoint at which the navigation toggles to mobile.
The last one, mobileBreakpoint, is perhaps the biggest change, as it’s referenced in conditionals throughout jquery-accessibleMegaMenu.js to determine whether navigation items behave on click or hover.
I knew I wanted to output a vector file, and while I was considering P5.js or straight HTML5 canvas, I stuck with Adobe Animate CC. Of course, that didn’t prove to be an easy path, as Animate CC strips ActionScript 1.0’s onClipEvent (remember that?!) completely, so I couldn’t even see the code.
I dug into my bookshelf and installed an old copy of Flash CS6. It was a surreal trip down memory lane, as I found myself looking up ActionScript methods that I used to have memorized 10+ years ago. Sure, Flash whined about Java SE 6 (my laptop was running 8) and it crashed several times, but I was able to extract what I needed.
Here’s an early draft of the mural. I opted against this because I couldn’t imagine anyone painting all that transparency on a wall!
So, once I had a for loop generating the pattern and a script randomly choosing which card to display, I wanted to output the SWF to a PDF. I looked into PDFConverter, scanned Quora, and explored a few ActionScript libraries. I then started opening the SWF file in a browser and tried printing it as a PDF. Both Firefox and Safari output it as a screen capture (PNG). Chrome, on the other hand, gave me the vector file I wanted, with one little catch:
As you can see above, it distorts the vector images. This being my best shot, I tried different ways to publish the SWF from Animate, but it always yielded the same result.
I finally tried one more approach that got me the print. By opening the SWF file in the standalone Flash Player, I was able to do a File > Print that retained the curve quality. The final print is below.
It’s on exhibit at WITF (with a lot of other great pieces!) until June 30.
A few colleagues of mine stumbled across this technique to save out bitmap images as SVGs using Adobe Illustrator that substantially saves on file size. I’ve personally done some testing with this approach (below), and my results yielded more than 80% file size reduction with no noticeable compression.
This approach is production-ready (provided your target browsers support SVG), and what makes it so eye-opening to me is I can’t seem to find anyone that has documented it online. Not only that, but Adobe’s documentation would lead you to exporting the SVG in a manner that doesn’t offer this file size benefit.
Here’s what I did:
I started with this image of the late 5ptz as a guinea pig. It’s 72ppi, 1200×800, and weighs in at 1.3MB. I copy it out of Adobe Photoshop CC 2015 and paste it into Adobe Illustrator CC 2015.
In Illustrator, I choose “File > Save As… > SVG”, NOT the “File > Export As…” option. Illustrator will prompt you to use “Export As…” for web-optimization, and while this is the correct approach for vector graphics, it doesn’t suit our needs for a bitmap image.
Here’s the final result, an 224kb SVG that looks identical to it’s 1.3MB JPG counterpart (!):
I did a series of export tests to see how I could achieve this, but saving from Illustrator seems to be the best approach. My results (with resulting output files linked):
All of these export options are converting the image into a base64 format, but the biggest reason the save to SVG version is so small is because it’s the only option that minifies the file.
Now, bitmap-based SVGs have a few limitations in the modern production flow–some servers aren’t configured to render SVGs, forcing one to use an SVG htaccess settings tweak. SVG bitmaps scale proportionally, but don’t have an inherent size that one can automatically rely upon when embedding into an HTML page. Lastly, some CMSs (WordPress included) do not permit uploading SVGs through the admin WYSIWYG, though workaround and/or plugins are available.
This out for yourself and let me know what you find. As for me, I’m already eyeing it as a solution for large website images that aren’t generated by the client.
I’m exhausted. I’ve had a full day of proposal writing, coding, and conference calls. I’m also under deadline for this month’s The Burg illustration, so what better time to procrastinate!
Last month, I did my illustration using Procreate for the first time (while visiting a friend in a hospital room in Denver). As I was about to get started on tonight’s illustration I remembered that Procreate has a cute little playback feature. So, here’s last month’s illustration captured on video (you can check out my son standing in as a model, and here’s the article).
It encapsulates the rushed nature I always get when doing these illustrations, as well as the luxury of working with multiple layers and resizing on-the-fly.
I made a recent trek to Colorado for a more somber reason than sighteseeing, but I certainly made the best of it. I sampled eggs Benedict from a different city every morning, sampled libations from various breweries after work sessions at coffee shops, and otherwise subsisted on sushi and Voodoo donuts every night.
My favorite portion of the trip (besides visiting friends) was on my last day visiting Estes Park and Rocky Mountain National Park. Some shots below (along with a few less-scenic shots from my trip).
This was by far the most beautiful electrical box I’d ever come across (in Fort Collins).
I spent my evenings playing XBox in a hospital room.
Representing Pennsylvania in Denver. Alas, my team lost to the healthier one.
I’ve been drawing digitally for over eight years, most recently on a Wacom Cintiq 22HD Touch. I know there are some that still appreciate the feel of physical art materials, but the ability to work in layers, scale elements, and switch colors has become ingrained into my workflow.
So, after nearly a month of anticipation, my Apple pencil arrived, and with it the promise to draw digitally on the go. I’ve fantasized with the idea of being able to lounge around in a coffee shop and draw on my iPad, but that scenario never came to fruition.
Wacom Creative Stylus 2 (top), Cintiq/Intuos Stylus, Apple Pencil
One reason is the hardware–I couldn’t find stylus that felt comfortable. I tried using a Pogo stylus back when it [seemingly] was the only stylus on the market, but found it compromised my drawing–it was an unwelcome restraint that handicapped my process. Later, I invested in both the Wacom Creative Stylus and its successor, the Creative Stylus 2. The first version had the precision of a child’s marker, and while the Creative Stylus 2 slimmed the tip, the palm rejection did not agree with this southpaw (a task that is partially the responsibility of software). Furthermore, I also didn’t care for the slippery plastic tip contacting my Otterbox, which I could only be exaggerated by a disc-tipped stylus.
In both cases, pressure sensitivity wasn’t an issue, but the experience felt so foreign that I intuitively made paperweights of the devices.
Another reason the coffee shop fantasy never came true is software. The iPad doesn’t support Photoshop (which remains my drawing software of choice). Sure, Adobe has released iOS apps, but many of them come across as demos compared to their Creative Suite.
Lastly is setup, I often need to draw from reference, so my office is the perfect environment. While I’m drawing on my Cintiq I can pull up image references on one of my other monitors. I toyed with the idea of getting a Wacom Companion, but the reportedly mediocre battery life paired with the fact that most artists work in their studios made me decide against it.
Multitasking on the iPad Pro allows for drawing from reference
I’ve been using the Apple pencil for a few weeks now, and…I actually use it. It’s easily the best stylus I’ve ever used for the iPad. It’s as responsive as my Cintiq, it doesn’t suffer any parallax (though, to be fair, the Cintiq is MUCH bigger), the tip offers a more natural resistance, and palm rejection just works. Sure, there are some things I don’t like–it doesn’t have an eraser ‘button’ on the other end (no iPad stylus does), it doesn’t have buttons along the side, and the cap, despite being magnetic, is just screaming to be lost. Determining the amount of charge the pencil had was also a bit of a challenge (look into widget notifications in settings).
As for native iOS apps, I migrated from Autodesk Sketchbook to Procreate and haven’t looked back. Procreate sports a simpler UI, supports a layered canvas up to 2732×2048, and exports to PSD. Just to make my iPad Pro productive, I invested in Screens for remoting to my laptop. It’s not intended for drawing, though, so I also bought Astropad, which allows for remote drawing in Photoshop and uses an ingenious delayed cursor effect to mask any lag.
The iPad Pro’s multitasking is a game-changer, as well, as I can simply pull up a reference image directly in Photos or Safari.
So, between the two, which is better? If money is no object for you, I’d still go with the Cintiq, as it eliminates the proxy to a final file and has a comfortable stylus with an eraser tip. Still, for nearly a third of the price, an iPad Pro with pencil is probably the next best option on the market.
On a recent trip to Philadelphia (primarily to hear UX expert Jared Spool speak at Wharton) I just so happened to drive by Eastern State Penitentiary. I was first introduced to this landmark by the work of several of my photography students, and the allure of its decaying state forced a spot on my bucket list ever since.
Many of the images birthed from peoples’ cameras are the same symmetrical, cliched pinups (including mine, below), but it remains a photographer’s playground. It was definitely worth the visit, if only to hear Steve Buscemi’s voice guide me around.
Using include files in my HTML templates has become an essential part of my web design workflow, and I’ve been using gulp-file-include in conjunction with generator-gulp-webapp. While gulp-webapp includes a gulpfile.babel.js file, it needs a few modifications to get HTML include files to display both when serving and when building.
I came across a helpful thread here on GitHub, though as I stated in the comments, I couldn’t get includes to display when building. Below is the complete solution. Basically,
I create a fileinclude task (L44)
I modify the html task to include a fileInclude() call (L57)
I include fileinclude in the serve task (L95)
I check for include file changes within the watch task (L114)
I'm a creative technologist at Hauck Interactive, Inc. and an adjunct instructor at HACC. I live in Harrisburg, Pa. with my wife and two boys. I enjoy good coffee, Trappist beers, Orioles baseball, and good design.