Thursday, January 19, 2017

Recipients of my volunteer grants in 2016

It was an awesome feeling to redeem 15 volunteer grants (of $250 ea for every 10 hrs.) issued by Adobe Corporate Responsibility Team as a reward for my volunteer work in 2016! A tough target for myself to meet in 2017.

Majority of these grants came from my work for the Cambodia volunteer project organized by Team4Tech, sponsored by Adobe, which was a great learning experience in itself, others from my personal volunteer work at local non-profits and some that were organized at Adobe locations. I have to admit that a big motivation for my volunteer work has been this reward and I find it very satisfying to be able to contribute to causes that I am passionate about. This in my opinion, the best perk of working here (in addition to the donation matches). I hope more employers follow along. 

Much bigger is the effort of these amazing non-profits that I dedicated my grants to:

David Sheldrick Wildlife Trust, getting the "elephant share" of the grants! They do an amazing work of fostering orphaned elephant babies which is very heart breaking to learn about, and reintegrating them back to the wild, some of them even visit them with babies of their own, help with anti-poaching, veterinary assistance for elephants and much more for the protection of elephants, rhinos and other wildlife in Kenyan wilderness.

Photo courtesy, David Sheldrick Wildlife trust.

Serengeti Foundation (of the famed Elephant Nature Park in Thailand)

American Bird Conservancy

National Audubon Society

Ocean Conservancy

The Marine Mammal Center

Sea Shepherd Conservation Society

Amazon Conservation Association

Friends of Children's Eternal Rainforest of Children’s Eternal Rainforest, Monteverde, Costa Rica

All these non-profits have a high ranking on a Charity Navigator and/or have amazing programs for conservation of endangered species. I heartily recommend these organizations to anyone considering donating or gifting!

Related links:

A Volunteer Journey to Cambodia: Prelude

Destination Ban Lung: Vignettes of a Volunteer Journey


A Volunteer Journey to Cambodia: Beyond a Single story

On the first day of our ICT workshop in Ban Lung, a remote town in northern Cambodia, during the second phase of our Adobe volunteer project, we met with a group of very smart and friendly secondary school teachersparticipants of our training. In the process of getting to know them better, we started out with a few ice-breakers and some quick in-person and informal “surveys" in which we asked the teachers to align themselves in groups of Yes, No, Unsure… corresponding to the questions asked or the statements made as we also did ourselves, moving along with them.
Pretty soon it got interesting (to me) with statements like "I have done a search on the internet in the last few days”, "I have used a desktop computer in the last week” or "I have sent an email in the last week” which led to realignments of teachers into all three groups indicating that they were somewhat heterogenous in their level of exposure to technology and/or devices. But here’s when it got very interesting for me…  

“I have used a mobile phone for in the last day” said the moderator, referring to the general purpose of "mobile activities"...

The entire group almost instantly shifted to the Yes section without a hint of hesitation and I felt like I was physically in this graph below, experiencing the mobile moment perhaps retroactively, in this remote Cambodian town... or was it the mobile-only moment? Although this was somewhat expected based on our prior knowledge, experiencing it in-person felt very exciting and surreal! It could've also been the excitement of encountering fellow mobile geeks on the other side of the planet.


https://twitter.com/lukew/status/591265766823034880

For the benefit of readers from other backgrounds, mobile moment is typically defined as the time when companies encounter that the majority of their usage and traffic shifts from desktop to mobile devices or more recently, mobile-only, paraphrasing Luke Wroblewski, whose name is now synonymous with mobile focused experiences and technologies.

But, you may ask... this is so 2013! Does this need to be discussed again? and I say yes, as this also correlated with my observations and UX affirmations I have come across in this project and elsewhere, seeing mobile users subject to experiences predominantly optimized for or a remnant of desktop oriented model. I specifically refer to it as affirmations, as these patterns, behaviors and technology issues have been observed and recorded world-wide and my fellow volunteers and I just got to see it first-hand!

It is indeed getting to be an increasingly mobile-first world, the "computer" is getting tinier by the day and it is about time we change our UX models to correlate with that.

Here are some more of my observations in the course of our volunteer project:

Internet connectivity was a big show staller 

Despite the penetration of mobile to the remotest corners of the world, the lack of internet connectivity keeping up with it made using internet based apps very difficult! Teachers quickly adapted to this by creating hot spots from their own cellular connection for use on laptop and tablets which ended up to be unreliable, not to mention economically taxing! Making some functionality of the app available without the need for internet, or considering of some form of implementation of Progressive Web Apps for your website becomes highly relevant now.



And, if you're thinking, oh my users will be so and so or have such and such, and of course will have unlimited internet and data, "you ain't seen nothing yet..." This reality of internet connectivity not being on par with the technology revolution across the world have been consistent with observations like the ones in the above video and from prior volunteers experiences across many parts of the world. Even if you didn't intend to, the entire world has become your users and it would only make sense to take advantage of it!

Even though we had picked apps that could offer some or most of their functionality without an internet connection for our training, we still had to climb through the big hurdle of getting the teachers to sign into those apps that wouldn’t let them use otherwise, which segways into my next observation.

Make sign-ups easy on your apps or better yet, no sign ups upfront!

Faced with internet connectivity issues, we almost had to spend more than half of our allotted time for some workshops in just getting the users to sign up for their apps although we at least tried to overcome the first hurdle of downloading the apps by pre-loading them into their tablets. Given the language and cultural barriers it was unsurprising to see people getting confused with sign up forms and getting stuck on things we take for granted that users will instinctively know about.  

Here are some simple things we can do to move along users with the dreaded sign-up forms if you must have them upfront, even if at the risk of losing half your users! 
  • Use example placeholders in input fields for clarity and give hints on possible issues with input. The word "user name" to a non-english speaker seems like "name of the user" especially when shown as the first field in the form without any hints, and it is also not "obvious" for the user to not include spaces or certain characters in user name or what to do when a certain user name is already taken. 
  • Provide hints on a strong password for safe user data. We figured the "national password" of Cambodia was perhaps 12345678 as we came across that everywhere!! This definitely made us realize we can't cut on the topic of internet security in our ICT workshop and now our teachers know better!


  • Provide sample inputs of date of birth and similar, as the format will not be obvious or the same worldwide. 
  • Make mandatory fields obvious and better yet, remove the optional fields for a short and sweet form!
  • Provide tool-tips or hints along the way to help with input entry and have input masks where necessary. 
  • Pre-fill fields when possible and also make it obvious that it is pre-filled!
  • Avoid using regional words, references or icons that may not be understood globally. 
This is by no means an exhaustive list but just some that struck me during my observations. There are of course books and articles written on this important topic! 


Since retention is the biggest hurdle that needs to be overcome by mobile apps the sooner and easier you can get the users to start using the app, the better!

Even after we got past the hurdle of downloads and sign-up forms and got teachers to the point of actually using the apps, there was the question of how does this app help me do things that I am already doing, better? and also making this obvious thus reducing abandonment, yet another challenge for apps. When there are so many logistical challenges to using an app it is hard to imagine that users are going to try out an app just for fun or curiosity. In fact this question was asked by one of the teachers how does the quiz app help him do things better in his classroom? Obviously that wasn't quite obvious. Also there won’t always be a team of volunteers “selling" the use case for an app if it isn’t already obvious.

Adding on to the list...
  • Most likely due to the mobile-first background and touch screen experiences, they don’t seem to notice the mouse pointer on links much, which points to the need for making hyperlinks more obvious and consistent.
  • Good to capitalize on mobile messaging platforms and social media as most of these users are natives in mobile forms of communication, and email was new and quite often non-existent until our initiation! 
  • Be mindful of language and cultural barriers in content and iconography.
  • I rejoiced as a front-end developer when I saw that they were aware of and used multiple browsers, and did not equate internet with IE and the fact that Chrome seemed to be their browser of choice! Well, that doesn't mean much if y/our analytics indicates otherwise, although it offers hope for the future. 
  • I found them to be distributed over a range when it came to familiarity with technology. While some had barely ever gotten their hands on a laptop computer there were others who were proficient in hardware or had advanced photoshop skills with a very discerning use of it. This seemed to be the results of the opportunities they had come come across.  A self-described auto didact who learnt it all from YouTube, proudly shared with me his beautiful before and after photos of elegant use of photo retouching with Photoshop!! 
  • Geekdom is universal! They love geeky stuff just as you and I. They love their powerpoint animations but discerning enough to not over-do it!  
  • They were especially keen on getting deeper knowledge and understanding of concepts or hardcore tricks and tips that would help them along their way.
  • Just like a developer focused on getting in harmony with the IDE and their core programming languages, they preferred to learn their "tools of trade” first... internet research, translation tools, word processors to help with lesson plans and presentational software to convey all this goodness to their students. 
  • They were more keen on educational apps and very aptly noted that tablets would help them the best in teaching skills more interactively to their students.
  • I loved their enthusiasm for exchange of knowledge asking and thinking about cloud sharing to share larger files, between each other and their new laptops and devices, due to the limited physical proximity of their group. Although time constraints limited us from teaching everything we wanted to in our proposed curriculum, I was thrilled to share more information in my one on one interactions and set up cloud sharing with these eager and dedicated learners. 
  • They were also quick to learn and adapt new technologies and foreign concepts to their own needs, very evident in the Chemistry teacher's thoughts on creating a Bingo game that he had come across for the first time, to teach elements of periodic table to his students or the ways in which all the teachers made the presentations based on our training, their very own, adding on to it being mindful of their necessities to teach their peers. They were the fastest learners I have come across in spite of all the challenges they had to face!
  • They did seem to be somewhat addicted to their mobile devices, although polite enough to not let it interfere during our common lunches or conversations as much. 
Above everything else, I found our Cambodian partners in this journey to be genuinely warm and friendly, super smart and inspirational!

Beyond a single story

Besides all this talk of UX and technology, what struck me most about this lovely group of people was that they were an antithesis to many of the pre-conceptions we see towards the "developing world" or the "third-world", two words that I detest using except when making this point. I am sure this is true of folks in many other parts of the "third-world".  As history tells us, all these countries had already developed way before the current "developed" countries had. 

As it may already be obvious from many of my observations above, they were no different from most of us in other parts of the world, although much nicer and friendlier. Lack of exposure or access to technology, economic conditions and a tumultuous history of struggles and exploitations seem to be the predominant reasons for many of these countries not being able to take advantage of current technologies. 

I was also happy to notice that women and girls raised beyond the societal and biological constraints and excelled in using and adapting to technology. Kudos to one of the teachers who pulled off a great presentation, while having to attend the workshop with her little toddler and taking care of her all along! She was a master multi-tasker! Women also seemed to be very entrepreneurial, working most of the businesses and shops efficiently and single-handedly, but unfortunately I came to know, in-spite of their hard work and lead, the societal norms didn't allow them equal rights with men!

It was a sad state of affairs on the environmental front with the usual problems of deforestation for palm oil, cashew nuts or rubber... any new trend that gets the cash flowing. The unbearable heat which locals said have gotten worse over the years doesn't seem surprising with the little flora that is left. The ubiquitous trash in towns and cities resulting from their inability to handle the omnipotent plastic that replaces sustainable local habits was also disconcerting. 

Although our encounter with students was limited, I cherished a few that we had. It was great to see school girls taking the initiative in getting to know us, taking selfies with us with their mobile phones and perhaps even ahead of adults in their familiarity with mobile. I feel the world seems to be getting more homogenous especially with the younger generation, those we refer to as Gen Z in the US. It now seems to be very ethnocentric to think our digital-native or digital savvy user is mostly a millennial when they could very well be a school girl or a school teacher in a remote village in Cambodia or a retired official or a farmer in India, orphans in Vietnam or school kids in South Africa, who have had their first encounter with the internet through their first mobile device! As Donna Morris, Executive VP, Adobe aptly notes in her article the millennials myth, it is increasingly important to focus on delivering globally inclusive experiences.

If you've made it this far, congrats and enjoy this inspirational TED talk by the eloquent Chimamanda Ngozi Adichie.




Related Links:

A Volunteer Journey to Cambodia: Prelude

Destination Ban Lung: Vignettes of a Volunteer Journey

Recipients of my volunteer grants in 2016






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.

Related links: Destination Ban Lung: Vignettes of a Volunteer Journey

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!

  

http://max.adobe.com/

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 (?!).

1
 2
 3
 4
 5
 6
 7
 8
 9
10
<details>
<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.
</p>
</details>

And a simple example of corresponding CSS below.

1
2
3
4
<style>
details > summary { transition: color 1s; color: $primary; }
details[open] > summary { color: $links; }
</style>


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.

https://www.nngroup.com/articles/mobile-accordions/
https://www.nngroup.com/articles/accordions-complex-content/

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
    https://github.com/mathiasbynens/jquery-details

    https://mathiasbynens.be/notes/html5-details-jquery

    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:
http://html5doctor.com/the-details-and-summary-elements/
https://github.com/mathiasbynens/jquery-details
http://blog.teamtreehouse.com/use-details-summary-elements

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.

1
 2
 3
 4
 5
 6
 7
 8
 9
10
<details> 
<summary>
<a name="faq3" id="faq3" class="faq"></a>
FAQ 1
</summary>

<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.
</p>

</details>

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

1
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.

1
2
3
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.

1
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.

References:


https://html.spec.whatwg.org/multipage/forms.html#the-details-element

http://caniuse.com/#feat=details
http://html5doctor.com/the-details-and-summary-elements/
https://mathiasbynens.be/notes/html5-details-jquery
https://github.com/mathiasbynens/jquery-details
https://www.nngroup.com/articles/accordions-complex-content/
https://www.nngroup.com/articles/mobile-accordions/

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! https://whatdoesmysitecost.com 
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. 
https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index


https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/june/speed-index--how-it-works-and-what-it-means/


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 https://imageoptim.com/ (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 http://danielmall.com/articles/how-to-make-a-performance-budget/
  • A Grunt task for keeping up with performance budget.
    https://github.com/tkadlec/grunt-perfbudget
     
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?


http://caniuse.com/#search=css%20shapes
 


http://caniuse.com/#search=CSS%20Grid%20Layout

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 ;) http://dowebsitesneedtolookexactlythesameineverybrowser.com/

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.

Resources:


http://thewebahead.net/
 

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 :)