Sunday, November 27, 2016

A Volunteer Journey to Cambodia: Prelude

As I was waiting at the gate of San Francisco international  airport, en route to Phnom Penh, Cambodia, the sequence of events in the first phase of this journey crossed my mind...

It all began early this summer when I saw an exciting and intriguing note in our Adobe internal news about a volunteer opportunity sponsored by Adobe Corporate Responsibility team to work with an organization called Team4Tech in collaboration with CARE Cambodia to teach 21st century skills to secondary school teachers and teacher trainers in Cambodia. Having allready been inspired by the amazing volunteer opportunities and rewards provided Adobe for its employees for volunteering, I applied with much interest and anticipation!

A big part of the application process involved writing a couple of short essays describing our experience and service motivation. After a quick couple of weeks, I was excited to hear that I was selected for an interview by Team4Tech and was thrilled to hear pretty soon that I was one of the six Adobe employees selected for the final team from a pool of close to a hundred applicants! I felt privileged  and honored to have been given this opportunity by Adobe and Team4Tech! The support and encouragement from coworkers and leaders at Adobe has been quite invaluable all along.

This post wouldn't be complete without writing about the amazing and motivating opportunities for employees at Adobe for volunteering at local communities, non-profits, pro-bono initiatives organized by Adobe or with our own favorite non-profits on our personal time, not to mention larger scale Adobe sponsored initiatives with non-profits and NGOs abroad such as this, all empowering change agents in our communities for solving social problems and creating positive change (#CreateChange). In addition to the opportunities, Adobe also sweetens the deal further by rewarding employees with a grant of $250 to a cause of employee's choice for every 10 hours of volunteer work at a registered non-profit!

Our Adobe team for this project comprised of six Adobe employees across the globe in four different time-zones! 

In initial kick-off meetings, we learned more about our collaborators, Team4Tech, whose mission is to advance 21st century education in underserved communities through technology volunteers by connecting technology industry professionals and solutions with high impact NGO projects such as the one in our current project, with CARE Cambodia, an international development organization fighting global poverty with a special focus on working with women and girls to bring sustainable changes to their communities.

The mission of our project was an exciting one...  to further  21st century skills like digital literacy, internet communications and education technology in secondary schools in Cambodia.

So what exactly did we set out to teach, and what are 21st Century skills?

After regrouping our team into three sub-teams, we focused on basics of computer and tablet Operating System; file storage and organization with introduction to cloud sharing; Internet security and communications;  digital literacy, productivity tools such as MS Office suite, education technology that would be helpful in classrooms for teachers, and more... We were working to empower teachers and teacher trainers in Cambodia with these skills and also motivating and enabling them to include this in their curriculum to teach their students. 

Set up with this mission, we got to work very quickly in our weekly meetings, individual and sub-team preparation and collaboration to plan for our in-country training sessions.

In addition to our project work, Team4Tech also facilitated discussions around articles and concepts that enable the team to cultivate leadership, empathy and skills critical for the success of the project such as
  • Global mindset 
  • Critical thinking 
  • Extreme collaboration 
  • Creative problem solving
  • Effective communication with cross functional, global collaboration
Some of the themes we discussed and experienced during this process were, synthesis of divergent ideas, dealing with ambiguity, prototyping and experimentation, taking risks and encouraging action, anticipating and managing change, inspiring others, strong self awareness, story telling, developing vision for systems, giving and taking objective feedback. 

We collaborated each week to create lesson plans and workshop presentations based on our objectives to deliver in-country.

We based our process on human centric design thinking involving, empathizing with the user, defining each of our objectives, ideating and prototype and our testing phase would be in-country and might involve further adaptations. 

Having converged in Phnom Penh from different parts of the globe, this is where we're at now, looking forward to meeting with our CARE Cambodia partners in Phnom Penh and traveling to several schools in Cambodia with our base in Ban Lung. 

Our team will be sharing our journey through this exciting  project over the next two weeks.

More to come!!

Wednesday, November 2, 2016

Highlights from AdobeMAX 2016

A quick digest of a few highlights from AdobeMAX keynote sessions today:
  • Adobe Sensei, an AI technology that uses image, facial recognition and more, now incorporated into smart searches in many Adobe products including Adobe Stock, Photoshop (sneak) and Lightroom Web.
  • Universal editing with symbols and a built-in Git-like (or better) versioning for design files in Adobe XD, now available on Windows10 and Android. 
  • Preview of Project Felix, a 2D-3D combination workflow that comes with ready-made 3D assets, textures and materials.
  • Preview of Project Nimbus, the next generation photo editor with cloud -storage and -sync. 
  • Templates in Photoshop.
  • Enhancements to Adobe Spark!
    A quote from the presenter: 
 “If you can use a plus button, you can use Adobe Spark!”   
- Michael Ninness
  • Character animation, 3D capabilities and more in Premiere Pro.
  • Ability to get DNG files from iPhone photos in Lightroom mobile, smart searches and more...
The Keynote sessions ended with an inspiring story of Adobe partnership with Exceptional Minds, a school focused on vocational training to help with self-reliance in autistic youngsters, by using creativity software.

Here’s a still from the inimitable Jason Levine’s presentation of Premier Pro highlights!

Hope to do more of these quick digest, TL;DR posts.

Wednesday, January 20, 2016

HTML5 accordion: Overview and an example

The concept of accordions/show more elements using HTML5 <details> and <summary> elements is not totally new in terms of W3C specs, but the browser support for it  has been somewhat sparse as of this writing, in spite of which there seems to be a considerable usage of this approach with polyfills. Perhaps I should say explorations for the lack of exact data on production implementations, but I hope this post inspires more developers to use this approach thus leading to more browsers supporting it.

In this post, I will give a brief overview of the specifications and explorations so far; examine the concept from a more holistic perspective of UX, accessibility and performance; share some quirks that I came across in my implementation and a few challenges that I solved to add on to the existing information contributed by other awesome developers referred in the links here and any others that I may have missed.

How does the HTML5 accordion code differ from the current implementations?

Briefly put, HTML5 based “accordion” (to keep it as a catch-all term) provides HTML elements such as a clickable <summary> element which is basically what it states to be, a summary of the information that you will see in more detail within the parent <details> element and the browser inherently adds an “open” attribute to the details of the summary element when opened without the need of any additional Javascript.

Furthermore, the open and unopen/native states are easily stylable with CSS including custom markers (arrow indicators) for the summary elements as :before pseudo elements which are discussed in much detail in some of the links I've shared in this post.

On the contrary, as you might be aware, traditional accordion code just makes use of a basic div content or <section> coupled with CSS and Javascript/jQuery. There are also examples of purely CSS based accordions making use of checkbox hack  or CSS :target pseudo selector which do have some issues and constraints.

Here's a markup snippet in brief. Note that summary is a child element of the details in the DOM (?!).

<summary>Summary of the information on an interesting </summary>
<p>Here’s where we add more details on what we summarized above. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris orci 
sem, suscipit id placerat eget, porta ornare turpis. Maecenas eget risus
eget ligula lobortis laoreet. Donec nec pellentesque elit. Nullam nibh 
mi,rhoncus pretium dolor et, mollis convallis enim. Ut accumsan 
faucibus tortor a porta. Nam sollicitudin elit urna, eu scelerisque 
purus venenatis vel. Aliquam non magna sit amet est pulvinar finibus.

And a simple example of corresponding CSS below.

details > summary { transition: color 1s; color: $primary; }
details[open] > summary { color: $links; }

With this brief introduction, I consider this an appropriate, useful and semantic HTML element for a major UI, UX pattern that we can harness with basic markup and CSS.

Why an accordion/"show more" element? 

As with any UI, UX pattern and implementations of it, I think it is important to do our due diligence weighing in on all aspects (usability, accessibility, performance) and justify its use before jumping in and littering the interwebs with questionable patterns, which we have a good many of and struggling to get away from.

Used appropriately, coupled with good information scent, especially on mobile, I think a 'show more'/reveal/accordion/FAQ pattern is helpful in presenting a user with progressive disclosure and the benefit of scanning available options before focusing in on one, instead numerous choices thrown all at once, while also conserving crucial mobile real-estate.

It might be stating the obvious (but still seen quite often), but it shouldn't be used to just hide the most important content of a page, eg. the top 5 things that we’ve chosen carefully that you will need on this page/portal/app which are now hidden needing a click to reveal, just beats the purpose of having carefully curated such content, and as with any other UX interaction pattern, the usability analysis and user behaviors on your site is what matters most, although we can use general industry studies and data as a starting point, many of which may very well resonate with the ours, such as the ones below.

I agree with the above article to a great extent that accordions should be minimally and carefully used on desktop experiences, although I feel the use of accordion for FAQs on content rich pages helps users with glance and focus from my own experience and other studies even if involving an additional click.

Current browser support; is it worth using now with a polyfill and what about accessibility?

While I wouldn’t recommend using this approach for something that can be accomplished with simple hide/show div script if that’s all you need on a page, but if you're using multiple patterns e.g. an FAQ accordion; a show more navigation element (for mobile) or a show more content feature... this helps consolidate all of them with one markup presented with multiple CSS (or common CSS when applicable), which I think is a big win with reducing/consolidating code and patterns.

The browser support for this is yet to be supported by major versions of Internet Explorer (still undead for many of us in analytics) and Firefox (really disappointing), so if one were to argue is this really worthwhile using javascript, jQuery based polyfills to accomplish, ironically, a markup to create an accordion markup without javascript (in many others that support it), my answer is yes, for the reasons below.
  • Semantic markup, clean and lean code when compared to the bloat that goes into many current implementations. 
  • Polyfills such as these below, address and fix accessibility issues

    while taking advantage of the browsers that already support natively. One can roll their own work-arounds for any specific options needed and as soon as more browser support becomes available just drop the polyfill script. 
  • Many existing cross-browser support scripts/polyfills are light-weight and accessible, more so than some current non HTML5 implementations I’ve seen on pages. Eg. jQuery UI library dumped in to just provide this one functionality!! eg. the polyfill linked here adds aria-expanded="true" tabindex="0" to the elements to be better accessible. To quote WebAIM, "A tabindex value of 0 indicates that the element should be placed in the default navigation order. This allows elements that are not natively focusable (such as <div>, <span>, and <p>) to receive keyboard focus".
If you want to dig into more details, here are some links:

There are some Vanilla JS polyfills as well in the above links.

Quirks, issues and additional information that I came across in my implementation

Not being able to deep link into a specific FAQ (e.g. http://localhost:8888/yourpage.html#faq3) was one of the issues/caveats that folks have raised in the above links/discussions, which I was able to address and make it work, as briefly described below, by treating each summary element as a named anchor tag, coupled with a few additional lines in jQuery below the mark-up.

Although I’ve tested this in multiple browsers, this has not been tested exhaustively just yet and I may be updating this post with more issues/solves if any. This markup and related script I added (for deep-linking into the accordion) is in conjunction with the polyfill script in the above link, so some of my notes and code may correspond to that (extending it) although this approach may very well work with other scripts for cross-browser support also.

<a name="faq3" id="faq3" class="faq"></a>

<p> <strong>Answer to FAQ 1. The details go here.</strong> senectus et netus et malesuada fames ac turpis egestas. Vestibulum tortor quam, feugiat vitae, ultricies eget, tempor sit amet, ante. Donec eu libero sit amet quam egestas semper. <em>Aenean ultricies mi vitae est.</em> Mauris placerat eleifend leo. Quisque sit amet est et sapien ullamcorper pharetra. Vestibulum erat wisi, condimentum sed,, ornare sit amet, wisi. Aenean fermentum, elit eget tincidunt condimentum, eros ipsum rutrum orci, sagittis tempus lacus enim ac dui. <a href="#">Donec non enim</a> in turpis pulvinar facilisis. Ut felis.


Get the location hash for the anchor link into a variable.

var currentAnchor = window.location.hash.substr(1); //substr(1) to get rid of the # prefix

Make sure you have checked for the presence of location hash with anchor name. Then find the details element closest to that anchor and set the attribute of that to open, so when the URL with that hash is hit, users will see the specific FAQ/content open.

if (currentAnchor.length > 0) {
jQuery('a[name=' + currentAnchor + ']').closest('details').attr('open', '');

NOTE: I used .attr as .prop doesn't work in non-compliant browsers. Also needed to include an empty value for open instead of 'true' as Firefox, implemented via the polyfill was choking on the latter and wouldn’t enable 'close' on the 'opened' details element within the focused summary element.

The above approach was also to make it work in Firefox which doesn’t seem to fire a focus event for anchor tags in the URL as opposed to something like below which worked in browsers that did fire a focus event on anchor tags in a URL (obviously our friend Chrome) by focusing in on the class of the summary element containing current anchor name in focus e.g. #faq3 and getting to its closest detail by (this). So if you're thinking like below, it didn't work cross-browser.

jQuery('.faq').focus(function () { jQuery(this).closest('details').prop('open', true); });

While styling with CSS, make sure you include styles for both details element and details .open class that the polyfill above adds to non-supporting browsers.

NOTE: As of this writing, the height transition of CSS didn’t quite work in spite of trying out a set height for details[open] element although I wouldn’t really recommend a set height for most cases as it is better left at auto height.

Well, it ended up to be quite a longer post than I expected for a 'simple' accordion. Hope you learned something new here and hope more browsers implement this soon and your analytics will show mostly browsers that support. We can only wish.


Friday, November 13, 2015

Thoughts and notes from, An Event Apart conference

About four years ago, the main theme, mantra in all of "web world", including social media, blogosphere, meetups and conferences was "responsive web" which pretty soon turned into "responsible web" as web pages seemed to have had an immediate need to go on a "diet" to do well in the speed and performance aspect, more so in relation to keeping up with the responsive aspect.

Although we feel comfortable enough at this time to say that the Web industry has matured enough to understand the concept of "one-web" that works well on all platforms and devices and the term "responsive web" or "mobile web" is hopefully getting obsolete and web now inherently means "responsive web" as it was always intended to be, I am not yet sure if we have reached the point where websites are as fast and lean as they can be. Striving to be fast and lean is where the web seems to be focused right now (or needs to, if it isn't already). This was aptly represented by the focus of the An Event Apart Conference in San Francisco, Nov 2015, especially considering the fact that there were two talks exclusively focused on this topic and many others also included a heavy focus on the same topic as well.

Here's my consolidated "Cliff Notes" of sorts from:

Design Decisions through the Lens of Performance by Yesenia Perez; Desgining for Performance by Lara Hogan; Modern Layouts: Getting out of our ruts by Jen Simmons and CSS Grid Layout by Rachel Andew.

NOTE: I may have added general contextual information and resources here, which may not have been directly elaborated on, at this conference.  All the resources and links included here are public resources shared by the speakers and others.

The need for faster websites

Although the need for faster websites is unequivocally established and felt (or has been made to feel, as in Facebook 2G Tuesdays), here's a bit of a refresher on the need for faster websites:
  • Average size of websites now — 2.16MB! Increasing every week! 
  • Online shoppers expected pages to load in 2 seconds — and at 3 seconds, a large share abandon the site.
  • People will visit a Web site less often if it is slower than a close competitor by more than 250 milliseconds.
  • 20% is the magic number that makes a web-page perceptibly faster/slower than its nearest competitor.
  • Visiting your website actually costs your users money! 
Ref: "For Impatient Web Users, an Eye Blink Is Just Too Long to Wait,” New York Times, February 29, 2012"

What makes up the page weight?

  • Images (biggest contributor)
  • Custom web fonts (note that iOS 9 and many others give an option to disable custom fonts make sure you don’t have any gotchas with system fonts). 
  • Third-party scripts (tracking, marketing analysis, user analysis, heat maps and more). These tend to cause more http requests as well.
  • UI Interactions that mostly translate to Javascrip/jQuery scripts. 
  • Stylesheets: Not the biggest contributor but can easily get bloated with overly complex layouts and numerous breakpoints (and frameworks if used in the 'kitchen-sink' model).
Apart from the usual Web Page Speed tests, time for first render etc. the term Page speed index was also discussed... Lower the better.

The best Speed Index score was 819. The average was 3,658 (median 3,106), while the poorest had a score of 8,582.

Why do we end up with bloated websites? 


Slow, heavy sites are a result of…
  • Poor planning
  • Poor communication
  • Poor awareness

Fast sites build trust.

Yesenia made a bold statement with "Performance is a design feature. Not a technical concern." What I think she alludes to is, if there have been decisions made at the marketing, UX and Design phases of the web project that cause it to be "heavy", no amount of optimization in the later phases will help you much to make it much leaner, so make sure it is built on strong but lean foundations. 

On a similar note:
"Deciding a page can’t exceed 500kB when a mock-up containing three carousels and a full-screen high-resolution background image has already been approved isn’t going to do you much good."
—Tim Kadlec
If an “approved page layout” already has a carousel/full page background image, textures, parallax scrolling, tons of web-fonts, videos, numerous JS/jQuery UI  interactions and “must-have” third party tracking scripts and much more, optimization won’t help you much to get your page load faster.

How can we change this?

  • Create Reusable UI patterns that use common CSS; similar UI interaction patterns > common JS > Less code.
  • Use the same basic pattern and add minor variations for different conditions.
  • Simplify.
  • Consolidate the number of colors and font-weights in custom web-fonts.
  • Choose inherently smaller size images (shallow DOF, less texture, fewer details/noise).
  • Optimize images further (has links for automation too).
  • Use responsive images. Thanks to Jason Grigsby's Herculean effort, we have an exhaustive 10 part essay on responsive images
  • Use svg, svg sprites and icon-fonts when possible (smaller sizes).
  • Use CSS to create banners, backgrounds, gradients and whereever it is possible to replace images.
  • Remove unnecessary elements in markup ('divitis'); Clean up code; Don’t use “Kitchen sink” framework elements; drop rarely used CSS/JS libraries; Create the same effect, interactions with fewer lines of code and use plugins sparingly.
  • When there are no other options, lazy-load below the fold images.
  • Load scripts asynchronously (taking care of dependencies).
  • Create a performance budget
  • A Grunt task for keeping up with performance budget.
The above are predominantly design oriented tasks related to performance optimization as discussed in the talk and there is a lot more that can be addressed in code and on the server and this is by no means an exhaustive list. In this write-up as I am focusing more on the former.

Key takeaways from the performance talks 

  • Prioritize performance from the beginning.
  • Set a performance budget and prioritize as a project goal. Retroactive doesn’t really work.
  • Who is responsible for performance? No more performance cops or janitors. Change Culture.
  • Include performance goals in project specifications and documents. 

Front-end technologies we can look forward to, get excited about

Talk from Jen Simmons on "Layout should serve the content" and Rachel Andrew on CSS Grid Layout.  

Notice something on the web these days...?  

Summary: Web is not print, but it is OK to borrow or be inspired from print elements that were previously not possible on the web, as long as they are accessible, compatible with multiple viewports and user-friendly. Be careful of tab-orders and screen readers and don't over-do, or go overboard.  Many of these technologies may not work in all the browsers just yet, but most may be conducive to be used as progressive enhancement at this time. Below are some of those, many of which we are already using in although in smaller doses. 
  • CSS Shapes
  • CSS Regions
  • Multi-column layout
  • Flexbox
  • Dynamic Grids
  • CSS Grid Layout

Where are we on the browser support for these?

If you are thinking... Why Did You Tell Me About All This Stuff I Totally Can’t Use Yet?!

The answer is: Do Websites Need To Look Exactly The Same in Every Browser?

Find out here ;)

To sum up in one sentence... Progressive enhancement is the key.

CSS Grid Layout

Specs are still not finalized on this, but in a better shape than flexbox. No confusion with multiple syntaxes as it happened with flexbox. Get involved and give feedback. May not be ready for prime-time/production yet, but can be used in prototyping as of now. Provides many options that aren’t available or hard to achieve currently, the most notable being separation of content and presentation and content choreography (yes, as in changing the content in different viewports without actually changing source order in the DOM). Of course a polyfill is in the works as well.


Thursday, September 10, 2015

Susy the class-less wonder; more reasons to "Grunt"

A more descriptive title for this post would've been... "Semantic, responsive frameworks with Susy (& Co.) and Sass", but obviously I am going for the cheese-factor here... Anyone recognize the allusion to a certain Seinfeld episode in the first part of the title? Never mind you newbies too young for Seinfeld ;-)

I have been sitting on the first part of this blog post almost for the past 5 months since I first used Susy "framework". Recently when this Smashing magazine post beat me to it, I almost thought rather not bother writing another "been there done that" post but I suppose this could be sort of a TL;DR version while also covering some quick basics, hopefully in a more overview angle.

I've made this into a two-fer including yet another reason to "Grunt" as there seemed to be a segway for that. Even if you have been using Grunt, stick around for this cool grunt task find.

Why a semantic grid?

You wouldn't probably be reading this post if you didn't feel the need for semantic frameworks... We all know the pains of frameworks in general, dependencies of framework files; mark-up littered with presentational classes (small-12, medium-6, large-3 and what have you) although some frameworks have mixins to prevent those; version updates; bloat to some extent if not used responsibly, although not much compared to all those tons of crazy un-optimized images on your page (can't help bringing that up).

To clarify, Susy isn't the only framework to use this semantic approach, just the one that I've used... I hear the latest version of Foundation, 6.0 (not yet released as of this writing) is also one that's going towards that.

A few key things you need to know about Susy:

It isn't really a framework per se as in, a file/s (grids and more) that you physically include in your <head> as in Bootstrap or Foundation etc. So it doesn't add any additional files/size to your Sass, or compiled CSS files!!

Although you can install it as a Ruby gem, I want to really stress that it can be used stand-alone without any Ruby dependencies. Just include the Susy folder in your project folder as below!

You can use it with Compass if you are already using it, but, not a dependency.

You do need to be using Sass though. Sorry, "Less"er folks... another reason to switch to Sass :-b Some Sass compilers didn't work at the time of my use (threw some errors), and the one that worked for me is the Koala compiler.

But, more importantly, although Sass is used while in the pre-processor stage, it isn't really a dependency in the final output. Once CSS is compiled, all the widths, columns and gutters are converted into straight percentages and can be ported into any environment as just straight CSS without the need for any framework files.

So then, you may ask, why not just use plain percentages manually to begin with? Frankly for the kind of complex responsive layouts we use these days, I'd rather keep my code "DRY" and not have to calculate percentages, gutters, margins, suppressing margins for the last-child, first-child and so on for every other div or complex product grids, with different configurations in each media-query etc.,  but rather focus on layout and quick delivery (set it and move on!).

So how does Susy does the "magic" of sizing your columns, with gutters, margins, margin suppression etc. The pics below are self-explanatory. 

You set all your grid variables like below in the settings file (which you will be importing to your Sass files...

You will be using it in your Sass file like below although not the best complex use-case scenario (btw, the breakpoints below are just basic Sass mixins I used. Nothing special referring to Susy, but the @include span is).

And you will get the compiled CSS output like below... Ta Da!

One more (rather two more) reason/s to use Grunt

Although it isn't quite possible to port Susy to Less in a completely automated way, there is a Grunt task for converting Sass to Less in general! Better to just convince others to use Sass, I guess. 

Here's a cool Grunt task for Sass > Less that someone has cared to share on Github.

In general if you just want to "cleanify" your pre-processor compiled CSS, eg. when porting/delivering it to another environment, perhaps as a front-end deliverable, here's the Grunt task to "cleanify" pre-processor output.

I've also wondered if all that ugly pre-processor CSS output with ungrouped media-queries for each element would cause performance issues, but I read this post testing that hypothesis which assured they didn't find significant performance issues with the pre-processor CSS output. Nevertheless it is still good to clean up . Kidding aside, these tasks can be really useful in real-world situations. 

To clarify, I didn't write the above grunt-tasks but just recognizing and linking to someone else's good work. I have personally used the second one and I love the output! Not sure how you would accomplish things like above (and lots more) without Grunt.

If you can think of some grunt-work, there's perhaps a Grunt task for that and someone has already shared it for the world to use. Good to use it and spend the time on something more challenging or less "grunty (or the interns could work on something more interesting  ;)) If you still aren't convinced to use Grunt, read the famous Chris Coyier's post on using Grunt.

A few notes from when I was trying to install Node and Grunt below. These may seem simple enough but will save you a lot of time wondering why your grunt task isn't running or some other snafu.

  • You need to first install Node JS (lots of details in the above post).
  • If Node JS install isn't working, install with sudo command.
  • You MUST HAVE the package.json (which will have your dependencies and your Grunt tasks) in your project root directory and the Gruntfile.js (which will have your grunt tasks).
  • You will be installing packages via npm (node package manager) and they all get downloaded into separate folders, but I found it way simpler to just put the necessary grunt tasks js files right into just the "tasks" folder off of your project root and just referencing directly in your Gruntfile.js (if you have it elsewhere, make sure you configure your paths right).

Hope this will be helpful to some. In general they serve as my own reference for later :) 

Friday, August 14, 2015

Client-side HTML imports: Tip of the web components iceberg!

Here's yet another article for a very simple and common use case for one of the web-components and a sneak peek into all the other exciting possibilities. Web components unfortunately aren't supported even by modern browsers with the exception of Chrome. But... fortunately for us who want to push the boundaries of web, of course there are polyfills, so continue reading!

What are web components?

I think two of these definitions give a good overview of what web-components are:
"Web Components consists of several separate technologies. You can think of Web Components as reusable user interface widgets that are created using open Web technology. They are part of the browser and so they do not need external libraries like jQuery or Dojo. An existing Web Component can be used without writing code, simply by adding an import statement to an HTML page. Web Components use new or still-developing standard browser capabilities".

"Web Components are a set of standards currently being produced by Google engineers as a W3C specification that allow for the creation of reusable widgets or components in web documents and web applications. The intention behind them is to bring component-based software engineering to the World Wide Web. The components model allows for encapsulation and interoperability of individual HTML elements."

Here is a very simple use case for one of the basic web-components:

Let's say you have many templates, components which share a header, nav, footer, search or some other reusable component... Frankly there isn't much of an issue in the context of a web-application or a server-side techology if you want to include and reuse those and you would resort to one of these many ways: "include", "import", "partial" "embed" whatever you call it, based on the server-side or client-side stack you're using (obvious from their nomenclature), the very basic and simple of them being the server-side includes, usable even on a static set of pages, without even the need to have the .shtml extension. So you ask, then what's the problem? But just think about it... shouldn't an age-old technology of including a basic reusable component/module be part of the basic HTML standards,  inherent of HTML, without needing additional client-side or server-side scripting or having to run on a server?

Yes, there is, and that's just one example of web components, the HTML import (code below)! As simple as it should be, but it doesn't work everywhere,  out of the box! Yes, this is dated as of 8/2015!

Apparently Chrome supports web components the best, but it doesn't render HTML imports locally even with a Node http server. So there you go! so near, yet so far!

  <link rel="import" href="/yourincludesfolder/nav.html">

So how would we approach this now, outside of a web-app? 

Let's say I am working on a static set of HTML.CSS, JS pages/front-end prototypes, one of the common patterns of front-end development that is becoming part and parcel of many workflows.

In a simple case of Brackets IDE (if I may call it that), that runs on an integrated Node JS process and hence has a "built-in" local server, one would think that it would be obviously be able to run a simple server-side include. But not yet, although it seems to be in the works.

If you have Node installed globally,  you would think you'd automatically have the http server. But no, you need to install it. OK, fine, you install and run the Node Http server in your project directory and then you'd be able to have a simple SSI? Wrong again! Node http server doesn't recognize SSIs or includes.

OK, we see there is an SSI parser for Node, let's install that for our project...

npm install ssi

You'd think, Ta Da! Nope, nothing automagic yet... with some more work/"pain" you can perhaps make SSI work or use Express JS and what not, but all I need is a freakin include!

So I say, fuhgeddaboutit! Just install MAMP locally and move on! And I did.

Install MAMP; change the httpd.conf or .htaccess file (rather just uncomment) to be able to recognize SSI, and if you'd rather use them with just .html and not .shtml, add below and you're done!

AddHandler server-parsed .html
AddHandler server-parsed .htm

Easy, peasy? Yes, but obviously after the above long suffering paragraph, that's not the point that I am trying to make here. Shouldn't having an include be more basic than that? 

We don't have to need JS application frameworks or server-side technologies or anything much else for an include and this is just the tip of the iceberg of what's possible with web components. They help us build reusable, stand-alone Web-UI widgets that are platform, framework agnostic and portable into any technology/platform. With frameworks coming up like the flavor of the day these days... Angular, React, Ember, Backbone, Node... and many organizations taking the Atomic Design, pattern-library approach, it makes perfect sense to have a componential approach to building encapsulated Web-UI widgets, eg. an accordion, image slider, alerts, ratings, comparison tables, video player, calendar or a custom flex elements to name a few and web-components make this possible. They also offer data-binding and exist outside of the application layer, hence separating the UI (front-end) and application concerns.

It seems like the picture is quite rosy so far, but some of the cons could be the other side of the encapsulation aspect of the scoped CSS (within the shadowDOM of the widgets), but if you are UI widgets reusing within your own organization, that should not be much of an issue except during re-branding perhaps in which case you'd probably be overhauling more than just CSS. Although I haven't used web components yet, the other cons I have come across seem more like the growing pain aspects of web-components, browser issues, polyfills/libraries slowness and such.  

I hope more browsers natively support web components soon... until then we have polyfills and Polymer (see below), although that is counter-intuitive to the very premise of web-components!

Here's a more detailed article by Lea Verou (representative of perhaps many more) with similar thoughts and more links to what web components are, can do and how you can use them now.

If you get disheartened by the above link, don't miss the resources below.  (from the horse's mouth)

I highly recommend watching the video below from the Polymer folks at Chrome which is quite encouraging, not to mention the lightest version of the library is currently just 19K and good to hear that performance is getting better with every version. (no article can be complete w/out a CSS tricks reference!) (get inspired).

Sunday, June 29, 2014

Thoughts on Human-Centric Design Thinking

What would you say if I tell you that you can build a lo-fi prototype of an app/experience/solution that your user actually wants and likes, with emphasis on the latter, in an hour?

Most might say, as I thought initially… One hour you say? NO WAY! But, I came back inspired after an hour long exercise/workshop in human-centric design thinking that this can actually happen!! Hope you read on, get inspired and use this process to your advantage.

This post has a brief overview of human-centric design thinking; an account of a human-centric design thinking workshop that I attended recently where the attendees came from all walks of life, departments and backgrounds… Marketing, finance, training, design, development; employees, interns, administrators to name a few.

The outcome was: Learning about whole set of needs, wants or challenges that folks face every day or an ideal experience they crave (albeit typically of the mobile-centric, privileged world) and a bunch of creative ways of solving them, with a prototype that each set of two folks came up with at the end of the workshop and shared.

A brief overview of human-centric design thinking

“Design Thinking” which might be more aptly called solution-based thinking or “design-doing”, evangelized by Stanford “d.School”, IDEO and many others is, in my understanding: A method of creating solutions to what users want, in an agile, iterative process that focuses on user feedback at every step to refine and improve the solution.

Tim Brown, CEO of IDEO, puts it this way:

“Opposing ideas and constraints to create new solutions. Balancing desirability, with technical viability and economic feasibility"


None really, even if you are skeptical about this process/exercise, chances are you will come out with a different opinion at the end.

Who should attend?

Pretty much anyone, not just a designer or a developer or a UX analyst.

What would help?

  • Willingness to ask, listen, observe and engage.
  • "Show, don’t tell"; and Do! Yes, Do with a capital D!
  • Be agile and iterative rather than refining all at once. I felt that doing the latter is what seems to get us stuck.

Here’s a brief overview of the process. I do have more detailed references at the end.


Many a times we might start with a product that we think the users want, go ahead and create a solution/prototype that we think that addresses the solution and THEN go to the users to present the solutions that we came up with, but the key to this process is to START with the users to see what they want and regularly iterate and refine the solution based on user feedback.


Pair up with a partner to find a challenge/“problem”: Design something that your partner (the user) wants. It could be a certain experience, mobile or otherwise, a certain app or a feature. Keep it focused.

The same challenge applies to your partner to repeat this with you for a solution/experience that YOU want, so each step described below is repeated twice.

At the end of the session you will have a solution or a prototype of what your partner wants and what you want from your partner. You will have some note taking materials, prototyping/sketching or craft supplies provided in the workshop to move ahead with each step.

The Process


  1. Interview the user on the solution needed. 2X 4 min (8 min)
  2. Dig Deeper 2X 4 min (8 min)

Graphics Courtesy: Stanford

Ask questions on why this solution is needed, how it helps the user and what helps. Listen and keep asking. The key is to not put-forth a solution at this stage or not have a bias on what would help or what YOU think the user needs and that helps drive the solution and the features.

I was surprised how much of our pre-conceived ideas might be proved wrong in this process of listening to the user’s needs. More often what the user needs is simple and less rather than complicated and more.


  1. Capture findings from the user (3 min)
  2. Define problem statement (3 min)


1. Sketch 3-5 radically different ways to meet your user’s needs (5 min)

Favor quantity over quality or feasibility or judging of ideas at this stage. The key now is to generate as many ideas as possible to present to the user and get feedback and open up a dialog.

Just start sketching and doing if you feel being blocked. Things will flow. Stick figures or blobs should work just fine.

Think low-tech and lo-fi. You don’t got all day! Make something that your partner can interact with. It could be sketches/“screens” that you can swap out based on interaction/input/“touch” or something you can craft quickly with a few simple materials to demonstrate, with some simple supplies provided.

2. Share your solutions and capture feedback

I feel this is the most important driving force of this exercise. Ask, and I repeat ask… why, how, what? Every time the user/your partner says he/she likes or dislikes something with the solution, ask them why on each and that’s what helps in improving your next iteration and a path for more solid and sound solution/product.

3. Iterate: Based on Feedback. (3 min)


Build or sketch your solution and get feedback. (6min).


Share and get feedback.

Note how many times the word feedback comes up here; the basis of human-centric design.

What makes this work?

  1. Defining the problem based on users need and input.
  2. Agile, iterative process.
  3. The time-constraint. It seemed somewhat counter-intuitive but the limited time-frame in each step which many attendees thought of as a constraint, helps in moving this process along quickly without time for over-thinking at initial stages; keeping the solution focused entirely on user-feedback.

What will I get out of this?

  • Learning the importance of asking questions, getting and taking user feedback.
  • Quick, creative thinking that you can use to solve problems at your work whether it is design, development, accounting or marketing or any other field.
  • Group Collaboration. Learning from others.
  • Learning to create a quick prototype of any solution. 

I was amazed to learn how simple were some of the common challenges that users faced; some interesting “needs” and the simple solutions they seek. Here’s just a sample of some of the “problems” that were addressed in the workshop.

  • A simple solution for someone to be able to learn, interact and work with the various exercise equipments and monitor their progress in the gym without the need of a personal-trainer every time.
  • Keep the cell-phone charged when not being able to be plugged-in all the time (solar, mechanical or other ways of charging)
  • Be able to talk to loved ones easily without having dropped calls all the time.
  • Not bother having to enter passcode to log into phone/mobile-device all the time. Being able to use finger-print or other scanning methods with fall-backs.
  • Being able to use a 3-D chat with family! which I thought was quite unusual and interesting!

Many more of what seemed to be a gold-mine of ideas for start-ups, entrepreneurs or corporations to improve upon their products or to introduce new products.

Some applications

  • As an exercise at schools to cultivate human-centric design thinking
  • Workshop for employees to promote design-thinking at institutions and corporations
  • Workshops at conferences
  • Team building exercise
  • Repository of ideas for start-ups entrepreneurs and hackathons.
  • Resource for anyone wanting to improve their creative process or human-centric design thinking
  • An experience that is fun and productive.

If you can do this in an hour, imagine what you can accomplish in a day or an entire week! Here's a video to illustrate just that: How Nordstrom Innovation Lab came up with an iPad app in a week to make the process of sunglass selection just a little bit easier (Oh the profound problems of our modern capitalistic world!)

Prototypes speed up the world! 
- Tim Brown, CEO of @IDEO

Intrigued? Want to learn more?

Here are some resources to read and watch.

An overview and history of design thinking (wikipedia) TED talk by Tim Brown.

If you think you can’t do this or won’t work for you or if you aren’t creative enough, here is a TED talk by David Kelly, Founder of IDEO, for your inspiration.

Talk less and do more by Tim Brown (or should I say “Less meetings, more doing” ;)).

Materials for further reading from Stanford and IDEO

The Virtual Crash Course Playbook by Stanford.

Stanford Bootcamp Bootleg.

Virtual Crash-course on design thinking by Stanford.

Toolkit from IDEO

Design thinking at Citrix: Igniting creativity to transform corporate culture: Catherine Courage at TEDxKyoto 2012