Jae’s Musings

So, ever since iOS 9, the publishing world and advertisers in general have been in a tizzy over ad blocking, and the apparent sudden downfall of media. In general, ad blockers are a very simple program. There’s a list of domains that are known to host ad scripts, such as Google’s DFP or Adwords domains, which are blocked from rendering on the browser. The most advanced version of these blockers connects to a server somewhere that maintains a database of ad serving domains which are populated via which domains users block the most.

Ultimately, the response from publishers has been over the top and silly. The Verge writes that ad blocking has killed the web. Forbes writes that ad blocking is the new piracy. Adobe claims that nearly $22 billion dollars in ad revenue will be lost this year due to ad blocking, a claim that UBS later refuted, stating that ad blockers would only account for $1 billion in lost revenue. All of this really climaxed though with Peace's volunteered exit from the app store, and the IAB considering lawsuits against content blocking creators.

Hopefully, the IAB reconsiders their stance since their arguement is rather silly. Web browser clients have the right to render and not render whatever they please to. If you are a developer or designer of any value, then hopefully you think of these things when it comes to designing and implementing a website. Publishers are not guarenteed the right to have their advertising display, whether it be through ad blocking or if the user simply uses a browser with Javascript disabled or completely non-functional. Should we also sue Google or Mozilla when our page renders incorrectly due to some sort of browser bug? To this end, the piracy arguement falls on its face, as the content of the website is still being rendered from its original source.

Ultimately, I feel as though publishers have overstated the apparent 'crisis' of what's happening in iOS 9. Content blockers in iOS 9 only work within Safari. Users who use Chrome, or visit links via in app links such as viewports rendered by Facebook or Twitter apps will thus not have ad blocking enabled, even if they do have ad blocking enabled in Safari. For publishers, I feel that it is likely that on iOS, the number of in-app safari users is skewed higher than average as that sort of content tends to attract a good portion of their users via social media, whos mobile apps render links in standalone viewports within the app.

Generally though, advertisers and publishers have made a mountain out of a mole hill. For advertisers, advertising onto mobile apps are just as easy these days as advertising onto the web, often times being able to recycle the same ad units from a desktop campaign onto mobile. For publishers, such a large margin of their iOS users are reaching their content from within apps anyway that I doubt that blocking within iOS Safari will have a heavy toll in revenue lost.

Email remains a rather crucial method for a product to connect to its users. It is, however, a point of discussion that gets the least amount of discussion in an overall product UX strategy. I will admit that Emails haven’t been given the once over I’ve felt that they should have in my recent work, but never the less I’ll discuss some of the logic behind email, and I’ll take about what I feel the future direction of such notices.

Responsive Direction

Email design on mobile is a rather complicated endeavor. For one, iOS remains the only phone OS that comes shipped with a native email client that supports css media queries. Android has lost such capabilities when Android 4.3’s email client started utilizing the gmail rendering engine rather than the webkit client shipped in the OS. Windows Phone and Blackberry, for what it’s worth, never supported CSS media queries in their email clients.

That is not to say that we cannot make emails work well on mobile devices that don’t support CSS Media Queries. I personally opt instead for one column flexible layouts in my email designs to work around such limitations. Utilizing a flexible layout allows you to support mobile devices with buttons, images, etc, that just feel right on mobile devices while not compromising the experience of the email at desktop resolutions. Additionally, the sorts of email we send out on my current project, Beatport Live, are notification reminders. These are simple messages with simple actions, and its easier to express our message in such a way vs something more complex like a marketing email with multiple goals and multiple messages.

For Beatport Live in particular, it remains important that our emails work well for our mobile users as well, especially as we do not have a native mobile app through which we could deliver native push notifications. Because our events are live and have time specificity surrounding it, we must make our emails available for users across any of our supported environments, and they must be able to easily and quickly achieve our desired actions when receiving the email. For that particular product, this was accomplished by creating large clickable areas, introducing links and call to actions at the top, middle, and bottom of the email. Still, part of me feels that the current top of these messages could use a more clear action, a button or similar clear identifier.

Threading & Naming Convention

An important innovation in email communications is the use of email threading. Its a subtle thing, but how your emails are threaded will have an effect on how they are consumed. Perhaps if this were a marketing initiative, it would make more sense for each email to have a unique subject line in order to avoid like messages from becoming threaded. In the case of Beatport Live, emails are sent when a channel you follow goes live. Therefore, the emails are titled |Channel Name| is now Live. The logic is that since you follow a channel and receive messages as such, then your messages should thread in accordance. This is useful in the case of Beatport Live as live streams, for the most part, eventually become recorded streams. As a result, even if an email is viewed past the stream being live, it still acts as a useful marker for viewing the recorded event.

The advent of push notifications

I feel that the current model of email messaging is still going to be the best method overall of engaging users and receiving responses for most use cases. That said, emails fall flat in one particular case, one where the message has immediate, time sensitive actions associated with it. An example of this would be a ticketing event. It is important to the service to be able to alert a user that tickets have gone on sale for a particular item at a particular time. Additionally, the user must act on that data immediately or risk having the tickets sell out before they are able to respond. Emails are loaded periodically, depending on the user perhaps as much as a full day, and require a user to have an email client or web client available to view the message. Emails are also permanent items, so while an email about tickets going on sale were pertinent to you when the email was sent, it certainly would no longer be so hours, days, months, or years past the start of the event.

For these cases, push notifications are a more desirable approach rather than emails as they tell users when an event has happened as it happens, and gives them a simple action to fulfill an email. Right now implementing push notifications are somewhat of a patchwork. On Chrome, we can utilize Google Cloud Messaging and service workers to give a similar effect to a push notification on a phone, albeit with the caveat of needing to have Chrome open on the client browser for the message to send. Apple offers a similar service for Safari users on Mavericks, albeit without the necessity of keeping the Safari client open. It stands to reason that Google’s solution will probably work on Firefox once Service Workers are implemented on that browser, and perhaps Project Spartan/Microsoft Edge at some point since its implementation doesn’t occur at the Chrome level as opposed to Apple’s variant which is heavily reliant on the OS X ecosystem. Additionally, this service worker solution will also work on Android devices that have Chrome installed, essentially duplicating the functionality of push notifications from natively installed apps, albeit without needing to have an app available for the platform.

Because push notifications present themselves to the user as native notifications, they are also able to have quick actions associated with the notification. If a user were to own an Android Wear device, a push notification would also display on their watch with a corresponding “view on phone” quick action.

That said, push notifications have to be used responsibly. Users have to opt into them, and they’re rather tricky to disable. Push Notifications, therefore, should be sent sparingly and should be limited for a particular limited set of data. It would be irresponsible to send push notifications for everything that a user follows on their desktop, however if the user opted for a reminder for a particular story/event or only important events for a particular subject, then the user will be more likely to interact with the notification and less likely to unsubscribe the app from being able to use it.

An additional limiter is that push notifications are a per device feature. A user who has opted into push notifications on their desktop computer will not receive pushes onto their phone. This likely will always be the case as a user has to give explicit permission for an app to use push notifications. Because permission is required, we should only opt to attempt to subscribe to pushes upon user action. If a user lands on a site and is instantly prompted to sign up for push notifications, they will likely refuse permission, perhaps also think the service has nefarious intentions.

The Grid is the harbinger of design services that don't need designers.

Designers tend to laud themselves as the type of professional that cannot be automated, and are thus safe from the impending wave of workforce automation set to hit the corporate world within the next decade or so. All of this isn't to say that people haven't been trying, however. Recently, there has been an intriguing new entry to the fold of WYSIWYG web hosting services called "The Grid".

The Grid promises to create original websites, not merely giving you predefined templates as one would get from SquareSpace or similar services. It's tech demos give rather impressive looking auto photo alignment and sizing, as well as modifying the colors of the layout based on the images it is receiving.

It's hard to say how much of The Grid is hype and how much is "AI design" as the service has yet to launch. The promotional trailer for The Grid suggests that most of the "AI" went into image processing services, namely image composition analysis, face detection, color manipulation, and color averaging. As for the composition of sites The Grid produces, it seems as though the service does use modularized templates defined by a human that the service can assemble together at will. Each component seems to be designed so that all components operate on a baseline grid, this way modular bits can be stacked and arranged amongst each other without breaking the site's visual alignment.

Still, none of this seems to be true AI based design. Granted, The Grid seems as though it can slap together a bunch of pre-made objects as the user sees fit, however it isn't actually going about creating a design itself. Even the more impressive bits such as color changes based on the images on the page is still predetermined by a human, and any average designer or developer could accomplish the same with color averaging and a well maintained SASS color variable tree. So then, if The Grid is not true, AI Design, what would autonomous programatic design look like?

The easiest start point would likely be to have AI modify a design that a human had created. Granted, this is similar to what The Grid does, however, the machine would chose alignments, sizing, colors, etc, autonomously and based on user interaction rather than simply what a human would perceive as good design. With this method, we would not have to have teach a machine the various rules, guidelines, and best practices that encompasses design, instead allowing the program to infer what good design is by analyzing the changes effectiveness based on user data. A/B testing, therefore, seems like fertile ground for automated design to get its initial foothold. The AI can be told an acceptable range of values to test (eg: the margin between buttons, color variances, number instances to display a particular type of object, etc), then determine the most effective instance of its manipulations based on user data like bounce rates, click through rates, time spent on the page, etc.

Although Adobe hasn’t abdicated the throne, it isn’t doing much to keep the barbarians at the gate.

Right now, I’m doing almost all of my visual design work with Sketch, the $80 OSX exclusive tool that combines the better features of Illustrator and Fireworks. For interaction work, I’ve adopted Quartz Composer, an Apple made tool that’s available for free with Xcode. The only Adobe program that remains in my stable is Illustrator, which, in my opinion, remains unmatched for vector asset creation.

So how has this happened? Adobe hasn’t really been doing much to support their digital space customers. With Fireworks no longer supported by Adobe, the company doesn’t really have a good visual design tool anymore. Photoshop is problematic for several reason, largely just due to the inflexible nature of raster based programs in relation to sizing and flexible elements. Illustrator doesn’t seem to have much official support to be used as a visual design tool, and bizarrely Adobe seems to see InDesign as a suitable web design tool. Perhaps it is easier for Adobe to retrofit InDesign to be an interaction design tool, but it certainly is evident of the problem that Adobe has: it has become too attached to its current lineup of products.

The reason that Sketch has seen success is that Adobe has allowed Photoshop to become bloated with use-cases, rather than making applications that exist to serve a particular functionality. I’ve hoped that the Adobe Edge products would produce a good successor to Fireworks, and perhaps Reflow is good enough for some, but not for any project I’ve worked on in the past few years. Reflow’s WYSIWYG system ultimately would be a larger pain for conversion to a dynamic site than simply hand coding the design, and truth be told, I don’t develop any static sites, so Reflow simply isn’t going to work for me. Additionally, I don’t only work on websites, but apps as well, and while designing in code would allow me to create usable prototypes fairly easily, the nature of mobile browser engines would make it problematic as an app prototyping platform.

Be that as it may, Sketch is far from posed to taking the crown. It’s still fairly buggy, and limited in features compared to Illustrator. I’ve also run into an issue with Sketch and how it uses OSX’s versions system, which silently took over 384gb of hard disk space due to saving large files. This was almost enough for me to drop Sketch entirely until I remembered that there is no suitable replacement within the creative cloud.

So if you've stuck around for a while, you've come to know that I periodically do updates to Flood Zone NYC both to improve the service, and also to flex my skill set and experiment with techniques I wouldn't really be able to do with client or in-house work. This time, Flood Zone NYC is getting updated on two fronts: on the website, and on its container applications.

The most immediate change, which is currently live, is the change to Flood Zone NYC's color scheme, which solves an issue that cropped up when NYC OEM changed the evacuation zones from a three tiered system to a six tiered system. The zones now change from purple, to red, to yellow from most intensive to least intensive, where as before they only changed from red to yellow. This new color scheme is inspired by weather intensity maps, providing a familiar system for end users to reference without much fuss. This also changes the legend lightbox, which now features the color of the zone in the left corner as oppose to using it as a background color.

The second change is an increase to the size of input and menu elements. Both have now increased to 40px in height, up from 30px. This allows for more reliable clicks, and allows smaller devices without proportional scaling, such as the iPad Mini or 8" Windows 8 tablets to be better able to hit targets, without burdening users of tablets that do proportionally scale.

Flood Zone's map color schemes have also been changed so that all non-water elements are in greyscale. Water remains as a very muted blue, which should avoid issues where background elements like parks changed the perceived color value of an overlapping evacuation zone.

For iOS, Flood Zone NYC's saved to home app mode will now detect that it is functioning as a stand alone app. When used in app mode, the paragraph about getting the app will be removed, and share functionality will be passed to the native applications for Facebook, Twitter, and Google Plus, rather than their web counterparts.

The Android application is being updated to address long standing bugs, as well as throw in a few features that being a native application allows. For one, like iOS, Flood Zone NYC will be able to detect if you are using the native application. The back button bug will be addressed and will effect the web application. I'm also hoping to create an offline mode created with native layouts largely because I'm using this opportunity to expand my reach on mobile development.

Something that's always been a fascination of mine is trying to figure out how to use new technology to create new experiences. This is something I got to play with for a bit during my time and Creative Realities in various methods. Lately, I've been playing a bit more with the speech recognition API and integrating it into my portfolio website. I had constructed a similar system for Creative Realities' website a year prior, though that instance of speech recognition was rather simple compared to the system I'm designing now.

Every mobile comp I’ve ever recieved has always been apple-centric. The mobile viewport is always within the body of an iPhone, the tablet viewport is always an iPad in portrait orientation, and “desktop” is usually either a chrome browser window for OSX or an iPad in landscape orientation. This always sets device oriented viewport sizes and expectations on responsiveness, often times I find without considering the middle ground between a large tablet like an iPad, and a small mobile phone like an iPhone. Considering the proliferation of 5” - 8.5” devices, it’s increasingly becoming foolish to ignore those devices.

Aside from web design, a shockingly large amount of projects continue to remain iPhone first, or iPhone only. App designs often still orient themselves towards iOS’s style guide, as opposed to drafting a digital style guide for the product or service. In a market with a wide variety of operating systems, device types, and emerging technologies, it seems increasingly foolish to place so much emphasis on one platform.

Moreover Android currently accounts for 52% of the smartphone market, compared to iOS’ 41%. Android accounts for 61% of tablets, while iOS accounts for just 36%. To not consider Android in responsive design, or to consider developing apps and services for Android at inception is sticking one’s head in the sand. Windows Phone and Windows 8 has much more modest marketshare percentages, accounting for a bit over 3.8% of the smartphone market and 2% of the tablet market respectively. To compensate, Windows Phone 8 and Windows 8 have nearly barren app stores. The two platforms may not be a priority for a service platform, but it does open unique opportunities for developers, since it’s far easier to be noticed on the Windows app stores than it is to get noticed on the iOS App Store.

Android 4.4 made an interesting choice by replacing its webkit rendering engine with the one utilized by the gmail app. If you know anything about the gmail app, it's that like it's desktop app it strips what it considers non-pertinent styling. Unfortunately for us, this includes media queries. So where does that leave us? Well, once Android 4.4+ becomes the dominant version of Android, iOS will be the final major mobile OS with a native client that supports media queries. Granted, I personally have seen higher usage from iOS users on my properties than on Android, but that doesn't change the fact that in the United States, Android makes up 52% of the smartphone market.

So I'm in the process of updating my portfolio website again, and I've been going through and recapturing images to use as demonstrations. During this process, I figured that it would be neat to capture video of my projects in working order on mobile devices, which is actually something that's been tough for smartphone OSes up until this point.

iOS never really had the feature developed, though people figured out alternatives by exploiting Airplay mirroring to mirror iOS output to a device, most likely your computer, which could then be recorded and manipulated for whatever presentations you needed to make. That said, this only solved our iOS problem, and only marginally since the video received was pretty low bit-rate, and thus plagued with artifacts.

Enter Android Kit Kat, more formally known as Android 4.4. Kit Kat intros API level 19 in the Android SDK, and with API 19 comes the screenrecord utility. The tool, accessible in a terminal environment via the SDK's adb utility, by default allows for 30 seconds of video recording at 4mbps, however you can manipulate the length of the recording and its bit rate to your hearts content so long as you are willing to tolerate whatever performance dips and storage you're losing as a result. I personally raised my bitrate to 8mbps and manually controlled the recording length by simply killing the function once my demonstration was done. For reference, my commands looked like such:

$ ./adb shell screenrecord --bit-rate 8000000 /sdcard/rei-touch.mp4

I picked up my Google Glass back in January from Google’s NYC Glass basecamp, an office in the upper floors of Chelsea Market, across the street from Google’s New York offices. I figured that if I were going to spend the $1,500 + tax to acquire glass, I might as well get every bit of my money’s worth by getting the tour of the device in person rather than just receiving an impersonal next day air package via UPS. I didn’t require much guidance in how Google Glass works and how to operate it, however I certainly can see why people would need a tutorial.

This year looks like it will be an interesting year for technology, but one of the biggest trends I'm keeping my eye on is the 'internet of things', essentially an extension of the internet to appliances, televisions, utilities, and other equipment, and while the prospect of having lights across the house change color and adjust themselves in sync with an app on an iPhone is an interesting concept, I'm more interested in the movement in that it signals a move to the importance of real time communication on the new internet.

So quite a few frameworks are becoming mobile in how they handle CSS. Responsive design has been taking a mobile first view for a while now, but mobile first CSS at first, to me, seemed a bit strange of a stance to take for web development, namely because of browsers that do not support media queries. The browsers in particular that becomes a worry with approach, is Opera 9 and under, Safari 3.2 and under, Firefox 3 and under, and IE8 and under. In practical terms however, the only ones we really have to concern ourselves with are IE8 and below, since Opera and Firefox users would likely have long been nagged to upgrade their browsers to a more recent release.

Under these circumstances, I've started to become more favorable to mobile first CSS, since if you are dealing with IE versions older than IE9, particularly IE7 and IE6, quite a large part of your modern CSS principles will not work, and if you are building for progressive enhancement, you're main CSS will likely be bogged down with Fallbacks, which with mobile first CSS we can isolate to only IE specific style sheets. Additionally, this gives us the added benefit of allowing our responsive design to function on mobile devices that do not support media queries, though how much of a benefit that is remains to be seen, especially now that the mobile web is largely dependent on touch interaction in its UI patterns. Most mobile websites would struggle with a tab interface like an old Blackberry.

Lately I've been considering the feasibility of creating consumer products in digital design. Nothing to replace my main streams of income, at least not for the time being, but side experiments that don't really need to make money but would be nice if they did. Why? Because more often than not client work is boring and doesn't provide opportunity to experimentation. Not to mention that I already have iOS and Android developers licenses, and I would like to make more use of the former since it is a yearly recurring license.

Similarly, creating themes for Wordpress, Drupal, and Magento would allow me to design and develop freely, while needing to meet certain real world constraints. Plus, I wonder of the profitability of a general theme vs a designed product for a particular client.