Jae’s Musings

A collection of thoughts from designer & developer Jae Hanley

[jaehanley]

A bit of an aside, but please enjoy the first episode of my new podcast with Sharee Miller, Two Tickets Please. In this episode, we discuss Star Wars: The Force Awakens. Warning: Spoilers inside.

[jaehanley]

On ad blocking

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.

The only real loser in all of this will be publishing networks, which for too long have been far too permissive in allowing ad clients to do whatever they please. This includes allowing advertisers to hijack scrolling, the force video playback even after a user stops said playback, and to flood client browsers with heavy and inefficient javascript. In the long run, there's really only one way to get around ad blocking, to bake it into the site's native JS, probably using the site's backend to fetch ads from a distributor like AdX and combine, minifiy, and distribute the JS to clients. The obvious drawback of this being that the client is limited in the number of simultanious request it can make and this being a hopelessly in-sync process. This would mean that ads would have to render last after all other in-site content loads, but I feel like for users this would be a welcome change.

[jaehanley]

Email, Product, and Push Notifications

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.

Web based push notifications are certainly something that services should be looking into at the moment; service workers as well for that matter. It’s hard to say that they are quite ready for prime time though. They certainly do have their advantages over email in certain scenarios, however as they are, for the most part, limited to desktops at the moment and are only implementable in two browsers, it isn’t wise to replace emails with them for the time being. I certainly do feel like for services like my own, and perhaps a few others, push notifications have a promise within the next two years, but for now, they’re very much an edge feature with an edge user base.

[jaehanley]

The Automation of Web Design

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.

In time, it would also make sense to do image analysis on the rendered view of the web page a a variety of common sample sizes, then use some basic rules of composition to determine if elements on the page are appealing in where they are placed and how wide they span. This type of automated design would likely not be impossible to do currently, after all we do have headless browsers, and it would likely be fairly simple to have one output screenshots of a webpage at a variety of sizes, use an image processing library to determine the layout, and then analyze the image to see if it adheres to various rules composition, scoring points for things like adhering to rules of thirds, golden ratio, inferred use of grid systems, utilizing a baseline grid etc.

[jaehanley]

The Death of Photoshop

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.

What Adobe needs now is a new program dedicated to the interaction space. It must have the ability to rapidly prototype interfaces on apps, and have those interfaces respond to interaction. But until that day comes, I’ll be soldiering along with Sketch and Quartz Composer.

[jaehanley]

Flood Zone Updates: Summer 2014

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.

In the long term, I also want to build a simple API to enable rudimentary support to wearable devices, namely Google Glass and Android Wear. The wearable version will allow the user to send their location to the service, which will then determine if their coordinates fall within one of the 1,200+ polygons which represents the evac zones, and return the result to the device. Make no mistake that this is going to be hard for my current level of skill with Java, but then again Flood Zone was hard when I started the project way back in 2011. I intend to use Flood Zone, and an upcoming clock project for iOS to dip my toes into mobile development.

[jaehanley]

Utilizing speech recognition on the web

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.

Utilizing the API itself is rather easy. Google Chrome, so far the only browser that supports this API, returns a string of text Google's voice recognition engine has understood, as well as a confidence score to its accuracy, ranging from 0 to 1. Naturally, this makes it simple to set an acceptable threshold for accuracy. Here's a code snippet for accessing the data

var recognition = new webkitSpeechRecognition() || new speechRecognition(); recognition.continuous = true; recognition.interimResults = false; recognition.lang = "en-US"; recognition.onresult = function(event){     var result = event.results[event.results.length - 1][0].transcript;     var accuracty = event.results[event.results.length - 1][0].confidence; }

Using the result variable, we can check the received string, and should it happen to contain a key phrase we're looking for (I recommend a phrase, a single word might be too common, thus leading to false positives), then we trigger an action in response.

Crafting the user interface for spoken commands is a measure more difficult. For one, the user has to be aware of the options which we have made valid. Additionally, the Speech Recognition API is currently accessible on Chrome for Android. In my particular case, that means needing to create an interface that also works responsively.

In my own usage of the API, I'm also using the Speech Synthesis API in tandem, largely because personal assistant implementations such as Siri and Google Now have proven that we would much rather have conversations with our machines than simply speak at them. Utilizing the speech synthesis API is also rather simple. For example:

var speechSynthesis = window.speechSynthesis; if(speechSynthesis !== undefined){ // Check for compatibility     speechSynthesis.speak(new SpeechSynthesisUtterance('Hello, it\'s me, your computer talking')); }

Click for sample

// <![CDATA[ function sampleSpeechSynthesis(){ var speechSynthesis = window.speechSynthesis; if(speechSynthesis !== undefined){ speechSynthesis.speak(new SpeechSynthesisUtterance('Hello, it\'s me, your computer talking')); } else { $(this).html('Your browser doesn\'t support this API'); } } $(function(){ $('#speech-sample').on('click',sampleSpeechSynthesis); }); // ]]>

Keep in mind that the Speech Recognition API will also detect audio generated via the Speech Synthesis API, so you'll want to implement a method of detecting wether or not the last spoken word was by the user or by the machine. If such a measure isn't taken, it is possible to trap your user in a loop of the voice recognition API failing to understand the spoken command, telling the user audibly, and then failing to understand the audible message.

In the end, this is yet another step in my own personal path of attempting to craft predictive interfaces. If you are trying to access the gallery, for example, it would make sense to offer you a contextual menu of all the times contained in the gallery, or give you the option to proceeding to the gallery index page itself. Though not currently implemented in my local build, it might also make sense to query the latest blog posts and a summary of said posts rather than simply push you to the blog index. It also doesn't hurt to get familiar with audio based inputs, since as of now it is one of two major methods of interacting with wearable devices, most apparently with Google Glass and Android Wear smart watches. These are areas that I think has massive growth potential, so from a UI and UX perspective, it is good to get an understanding of how best to utilize speech with digital interaction.

[jaehanley]

When will Android and Windows Phone escape from the design ghetto?

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.

So, when will Android and Windows Phone escape from the design ghetto?

[jaehanley]

The death of the responsive email

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 what can we do in preparation for the death of the responsive email? Luckily for us, Gmail and Android 4.4's email client does support liquid layouts, as do other non-responsive email clients like Windows Phone's. It will require a shift in how emails are designed, moving away from image heavy complex layouts to designs that work well at a variety of sizes in a single column, but all email should be simple for the reader and not be reliant on images anyway.

[jaehanley]

Android screenrecord and you.

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've actually been pretty happy to find that performance has been pretty good with this command, and much to my surprise, seems to work just fine across all of my non-rooted Android 4.4 devices. It even works on Google Glass, which is nice since it would otherwise be a major pain in the ass to demonstrate products created for the platform. Presumably, this function will therefore also work with Android Wear devices when they ship in the summer.

[jaehanley]

Three months with Google Glass

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.

That said I’ve found the experience to be a bit rough in how it’s put together. For one, you can’t really remove a card from your timeline in current or previous interactions of Glass’ OS. If you are like me, then your timeline will get cluttered with somewhere in the neighborhood of 50+ notifications per day, and having to traverse backwards in time to see what you missed at the end of a workday can be rather tedious. Something I would like to see is the ability to continue from where I left off on the timeline from my last interaction rather than just starting from the beginning every time I exit standby. Perhaps a large swipe gesture should place me back to where I was before. Generally, however, I’m rather pleased with the device as a repository for news alerts and general “interesting stuff” reader.

That said, I do think that the public has gotten to the point of hyping Google Glass to points beyond what it is actually capable of doing, or what users will actually want it to do. I can’t go a day without someone asking about Google Glass, and almost always, there is an expectation Glass has given me Minority Report vision, where information about my surroundings and the people within them are accessible without even a command. Those people are going to be rather disappointed to find that the battery, at best, can muster about 8hrs of battery life with average use. The sort of science fiction Google has purposefully allowed to spread is impossible with Google Glass, at least not for a sustained period of time for more than an hour.

Services that see Google Glass as the second coming of geolocation based social networks are going to be in for a rather rude awakening once they realize that the Mirror API, Google’s cloud based method of supporting Glass, only reports user location occasionally (to preserve battery life), and that native apps built with the GDK have to be specifically activated by the user and, as of now, can’t always run in the background. Generally, I think that the best GDK applications will be simple applications that allow the user to post updates or share content using the native sharing and posting features, or utility applications like Compasses, timers, and calculators that provide some practicality to them. The best Mirror API applications will integrate with web services of some sort, like social media, news, data services, etc, and provide either subscribed alerts, or alerts built around user activity (eg. If last.fm sees that you’ve listened to a particular artist a lot in the past week, and also happens to see you in an area where the artist is scheduled to perform, it can pass a heads up, and give you the option of adding the concert to your calendar). The best apps overall will integrate with phone or desktop apps, where you can do simple actions via glass, but more complex actions happen on your phone. For example, one of my favorite Mirror API apps is essentially an RSS reader. It sends me a bundle of news updates once an hour. I then go through the stack and select the most interesting headlines to be saved to Pocket, an app on my phone that allows me to read the story at length on the go.

Aside for the technological and design issues of Glass, the social implications of Glass are a rather interesting subject of controversy. Google Glass is not really a device that lends itself well to privacy intrusion. The device’s recording is limited to 10 seconds by default (that pesky battery life issue), and when the device is recording, Glass’ screen is visible for all to see. Keep in mind, Glass contains its monitor in a transparent prism, so everyone can see when and how you’re interacting with Glass. People also feel as though Google Glass allows government agencies more intrusion into your daily life, but as I said in a previous post some time ago, privacy in today’s technological environment is an illusion. Glass relies on your phone to gather location data, a sign that Glass doesn’t have have an A-GPS unit of its own, but rather relies on your phone and the MyGlass app to provide that data for it. Actually, on its own, the device is more or less useless. It can’t connect to secure WiFi networks independently, and is pretty heavily tied to one’s Google account, meaning that if the device were stolen, a thief would find himself with a $1,500 brick. A point of concern would be the camera and a government agency or unscrupulous developer using it to record sensitive information, however with the battery life the way that it is now, I’d imagine that you’d only manage to get maybe an hour or so of streaming footage before the battery died. Not to mention the data spike and battery drain the phone Glass was tethered to would experience. That said, if I were in the business of crime, I certainly wouldn’t want to bring an expensive face-camera to a drug buy.

Glass has, however, become a symbol of class warfare in some parts of the country, namely in the valley, where employees of companies like Google, Facebook, Apple, etc, are gentrifiers and have raised the costs of living and real estate. Since NYC has a relatively small technology scene, I haven’t really had any first hand experience with such bias in regards to Glass, but such an issue is nothing related to the device itself, but rather to the social issues that tech companies have placed onto the areas they inhabit.

Overall though, I find that people are more curious about the device than anything else. I can’t go a day without someone coming up to me and asking me about Glass in the following order: [“Is that (Google Glass/a camera)?”||”What is that?”] [“What’s it like?”] [“What are you seeing now”] [“How much does it cost?”] [“Is it worth it?”] The novelty of it was fine for the first week, but now I’m tired of answering these questions every day. Eventually you come to realize that you’ve spent $1,500 to become a Google salesman, and that being a B or C list celebrity must get really annoying when people ask you about that movie you were in for the 7th time that day. That is it worth it question is an interesting once since the answer is usually yes*.

*If you are a developer who wants to be the first to market with some sort of app, and if you believe that Google Glass will sell next to its competitor product/cousin Android Wear. For all others the answer is no, not yet. Google Glass certainly feels like a 1st generation product. The battery life isn’t very good, and it’s still more concept that fully fleshed out product. I personally find it useful and would prefer wearing it than not wearing it, but for you non-developers/designers, you’ll find about $500 worth of product value with a $1,500 sticker price. That’s ignoring the cost of the optional frames ($250, vastly improves the aesthetics of the device, and honestly should come standard in a consumer release) and the price of prescription lens, should you happen to need them (I did, $350 for the lens btw, without insurance subsidy). The official selection of apps are limited since this is a pre-release product, and side-loading apps requires a bit of technical skill, and are subject to break with every OS update. It would be much wiser to just wait until a consumer release to pick up a pair.

[jaehanley]

2014: The internet of whatever.

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.

What I'm fascinated with are the implications to how information will be passed to users in the next year. Traditionally, you would go to a website, it would query a database, and show your information after it had already been added. Even newer services have generally only occasionally updated a feed, and usually in batches. What happens now when you are alerted to changes instantly? What happens when your devices start to work in sync with one another rather than just being receptors of data, and what happens to cloud services, which now suddenly become hubs for devices to connect to, rather than just to pull information from?

I'm also particularly intrigued by Google Glass, not necessarily in the technology itself, but rather what it's impacts will bring to the wearables space. Consider the sort of inferential data that modern mobile devices are able to gather. Your smartphone certainly knows where you are since it more than likely comes with an A-GPS chip, and, by extension, so does Google Glass since it requires a tether to a smartphone. Since Google Glass knows where you are, it could be used to send data to services who would then push relevant content towards you and your activities. This can, and will, lead to uses of the technology being able to inference your location, your wants, and send you information about those wants before you have a need to access them. For example, if you were standing outside of a train station, Glass could see where you are located and quickly display a timetable of the trains as well as a real-time estimation of when the next train will arrive. Because you usually tend to travel to specific locations on specific days with general arrival times, Glass could tell you whether you would reach your destination one time and suggest alternatives routes that would get you there faster, with an ability to swap to turn by turn directions for the alternative route. If the MTA maintains a streaming API service, then Glass could be alerted to any delays, system catastrophes like a stalled train or police investigations, and alert you to them before entering the station.

Alternatively, if you happen to be in the area of a major event, you could be alerted to it in real time (this of course needing news that is geocoded, a task in itself, but lets presume for the moment that it is there), and the option to open an app like TuneIn to listen to news reports from whatever station happened to break the news first in a language you understand.

[jaehanley]

Responsive web and CSS

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.

There is also the use of CSS preprocessors like SASS and LESS (SASS being my preferred tool) which will easily allow for compartmentalization of sections of your CSS, which comes in handy for porting sections of code around for various stylesheets or fallback stylesheets. Honestly, I wish that one of my current projects had been built CSS first, as it really would have saved quite a bit of effort in the code, and would have allowed me to more easily support outdated browsers.

[jaehanley]

Consumer goods

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.

I don't really have anything to announce on that front yet, though there is one project that is sitting on the bubble at the moment.

[jaehanley]

Mobile revolution: UID and web app synchronization.

Lately I've been playing around with the iOS7 beta on my iPod Touch and iPad Mini. I've found the experience enjoyable, but what's really struck me is the addition of Air Drop, essentially Apple's answer to WiFi Direct, and, with a bit of snark, referred to as the alternative to NFC transfers commonly found on newer Android devices. Like the NFC transfer protocol on Android, Air Drop allows users to send simple data like photos, websites, and data from apps between devices with a tap. What intrigues me are the possibilities this opens up for web apps. Consider the following circumstance. I have a large album of photos that I want to share to a friend on Dropbox. In the past, if I wanted to send those photos to my friend, I'd either have to send him an email to retrieve the files, or I'd have to have the images on hand on my device, and then cumbersomely transfer them over to his device, upon which he'd have to upload it to his Dropbox. What if, instead, we were to simply provide a unique identifier link that lasts for the session of the connected user that, when shared, would allow for instantaneous transference from one user to another? We don't require anything for this on the front end, we can build it all into the back end, making it so that we can identify the link to be in reference to the file, and the user, if logged in, will simply have the files added to their directory, or be prompted to log in to do so. The possibilities become ever more intriguing when we consider pairing this with additional technologies. For example, if I were to develop an HTML based mobile game with multiplayer, I would currently have a difficult time trying to get my friend to join in with me as well. For one, he would have to have some log-in in order for me to identify him as the user that I want to play with. Likely there would be a need for him to be invited to play, which would involve a third party like Facebook, and in all is a bit cumbersome. However, with the unique identifier, I can just share my current address with my friend, and he will simply be paired into my game using WebSockets upon arrival, without the need for notifications, needing to find one another, or involving third party clients. At the very least, client side peer to peer connections will enable us to make physical connections which are difficult to produce in today's web environment. Granted, this technology has been present for years on Android, albeit disabled by default and rarely utilized due to Android 4.0+'s relatively slow adaption. However, the stars are becoming aligned on this particular path. iOS7 will likely retain the high adaption rate of previous iOS versions, and Android 4.0+ will likely take over the marketshare lead sometime early next year. While a ubiquitous solution like Bluetooth Transfer is still not as user friendly, Android and iOS's ecosystems are building robust web page sharing technologies that, if utilized well, can enable social experiences that we currently had not the means to utilize, and that will make way for innovation.

[jaehanley]

When pretty beats practical

"Wouldn't it be cool if" is the phrase that is usually the precursor to either an amazing idea or a terrible one. I've no idea what the percentages to either is at this point, but I find few exceptions or middle ground in its execution. It's a statement of blind, raw concept, and as such unfounded in its proposal. There's nothing wrong with it per se, not all good concepts have a basis in reality, at least not in its conception. However, "wouldn't it be cool" tends to have a funny way of pushing concepts that should stay concepts, or guiding us in ways that distract from our main goals. I find that when design flys off the rails at an agency, its because of some sort of feature creep or request. I find that often it doesn't come from design, necessarily, though from account managers, marketers, sales, or perhaps spinelessness towards directing a client away from an idea because we can exploit it and make more money that way. I do have to wonder about how practical any of that is. Sure, we appease the client's tastes now, but what happen when the proposed idea no longer is in style, or if leadership changes on the clients end and they decide that they hate the work? What happens when someone higher up on the food chain realizes that the additional services and features we are proposing do not solve the main issues of the client and aren't all that well thought out to begin with? I find that probably the number one snake oil of choice for agency "upsellers" is social media. It taints so many of our projects these days and does nothing practical for us. I'm not arguing that social media marketing isn't important. Far from it, I think that a brand with a large audience should maintain Facebook and Twitter profiles at the least, with larger or more forward looking companies checking out up and come-ers like Vine, which looks ripe for the Old Spices of the world. Placing a facebook or twitter feed in your app, however, doesn't make you social. Placing a social media wall in your lobby or on your sales floor doesn't make you any more social, and doesn't provide you with an real value. Yes it would be cool to see a stream of tweets, but I don't see how a tweet feed in your gallery will help your B2B sell wrenches any better. Worst is when "wouldn't it be cool" features overtake practical additions to a website or service. It would be more practical to spend more resources to make your website mobile capable rather than trying to figure out how your generally content-less site could use parallax scrolling. Yes, while carousels look nice, it isn't wise to bundle three concurrent ones next to one another since they will be awfully distracting, causing your user not to pay attention to any of the content there. "Wouldn't it be cool" needs a filter, or at the very least, the willingness to put the bullshit aside for things that fulfill the needs of the client and the customer. We are designers. Our job isn't simply to make things pretty, but to make things work. The style is the last thing that should be in your mind, it should be the function. Form follows function: remember it, keep in in your hearts, and never reverse the two.

[jaehanley]

Flash Floods & Flood Zone

So, occasionally I hop over to my analytics and see what's going on with the traffic for my websites, and see spikes in traffic for Flood Zone NYC. Naturally, since Flood Zone is a local site, its traffic is effected heavily by local news and events. Baseline, the site gets about 100 visitors per day, which I find fascinating considering that I really only built the site in case of hurricane related emergencies. On Wednesday, Flood Zone saw a mild spike of 472 visitors. So why? Well that's because the emergency alert system was activated with an alert for flash flood warnings, causing users to search for flood maps, thus landing on Flood Zone NYC. Unfortunately, this isn't data that I've presented, and it illustrates a few issues that I've run into with Flood Zone as of late. Anytime there is a mention of "flood" pops into the news, Flood Zone NYC's traffic spikes, and unfortunately I don't have data to provide for every instance of flood related concerns when it comes to NYC. I find this acceptable, because that is far outside the goals of what Flood Zone NYC is supposed to be, a hurricane evacuation zone awareness tool. Still, it is something to consider for future revisions of Flood Zone NYC. I have, for the past few months now, tried to attain some sort of digital copy of the proposed FEMA flood map, however I've had trouble finding usable versions for Google Maps. Additionally, I wonder if such additions will just lead to more inevitable feature creep that will dilute the minimal experience that Flood Zone is built on. There is the matter of the name as well. "Flood Zone NYC" implies that this is an informational site about flooding in general, though what is discussed is really only flooding as it relates to hurricanes and tropical storms. I'm sure that "Hurricane Evacuation Zone NYC" would be a more informative title, however it doesn't convey the general concept as well as Flood Zone, and pigeonholes it into what it is at present.