Friday, December 13, 2013

Responsive redesign of an HTML newsletter

As a precursor, read about my previous experience/success with a basic HTML email newsletter and how to track your email campaign results with Google analytics.

I recently came across an article by Zurb that said "Over 40% of emails are opened on a mobile device". Correction: Actually it is way more than that (79%) based on this data on Luke Wroblewski's blog.

This made me think it is time to extend our love of mobile optimization to HTML newsletters as well.

Another question that has surfaced often in conversations was, "What do most people do when they come across HTML emails that they can't read well on a mobile device?"
Based on what I heard from many, and my own experience was that they will not save it to read later on a more compatible device (desktop/tablet) but would mostly delete and move on.

I am sure many of us can relate to that, especially at a time when we are bombarded with tons of emails every day and ruthlessly send as many as we can, to trash.

So, responsive email is more of a need at this time, with the proliferation of mobile devices, our own experiences and the above factoid from Zurb.

General notes about responsive emails:

    Although I find creating responsive websites easy, on the contrary, I find there is a lot more pain-factor involved in this relatively tiny piece of responsive email (vs a website), which I think is mostly because:
    • Email clients are way behind even the worst browsers in terms of web-standards/technology and way more diverse in their presentation and support, many that don’t make any sense at all!
    • Unlike websites, it is not easy to check your fixes just by the refresh of a browser window (every time you fix something, you need to send the email out, yes, even on litmus) and check emails.
      Word of caution, just as with browser simulators it is always best to check on as many real email clients and devices as possible and not just rely on litmus tests. I found that actual result was way worse than what litmus test showed me.
    • You need to code like it is the nineties, but still use progressive enhancement for newer mobile email clients with media-queries, balancing a mixture of old and new. 
    • Outlook is to responsive email as Internet Explorer is to responsive websites.
      I found to be even worse than outlook desktop app and about 80% of my testing and fixing was for some of which had to be left at a not so pretty state as there was no way to fix them in spite of numerous trials (eg. Weird blue underlines irrespective of the style, justified text in some cases etc.).
    • Many of the proposed solutions online didn't work for So, there are some things you just have to end up accepting due to the limitations of email clients. 

    But, don't lose heart. It is lovely to see the mobile-friendly end product (think of how enticing, easy-reading it would look to your users, esp. compared to all other un-optimized emails in their mobile inbox), not to mention the joy of squishy-fun factor for you (still hasn't gotten old for me)!

    Just don't assume to square it off in a day when you are doing this for the first time. It only gets easier for the next time!

    Technical Notes:

    • Even if you have designed and coded regular HTML emails before, start out by reading some articles on basics (many references at the end) and why things are done the way they are, so you don't blindly follow a boilerplate or get into trouble because you overlooked something that shouldn't have been done.
    • Do not start without a boilerplate template eg. Litmus, Zurb, Antwort etc.
      Why? They take care of common issues that have been already found and addressed so you don't have to spend additional time reinventing the wheel. You will still have enough to deal with when you create your templates.  
    • Even if you do start out with a boilerplate or sample template, make sure you send it in an email to test it before you customize and work on your’s. I found some that I started out with, didn't work responsively (perhaps they were just quick run-through examples and weren’t tested) and I had to create my own, based on the knowledge from several articles and examples.
    • Keep it as simple and concise as possible. Mobile-first approach is ever so important in this.  
    • I really liked the strategy explained in this article. I used a mostly single column layout and two columns only in one section. 
    • The table spaghetti code will be much cleaner when you keep it simple and minimal which you will appreciate!
    • I didn't use a responsive email framework (it was a bit too much for my purpose). Zurb has created responsive framework called ink if you want to try it out. 
    • Although I generally use code based HTML editors like Sublime Text, I found it helps to code in a visual HTML editor like Dreamweaver for this. As it is old-fashioned code, with all styles inline (kinda icky!) it is easier to copy and paste similar sections in design view as it copies the inline-styles associated with each paragraph, list item, link etc. (which is a must).

    A general overview of the layout, code:

    • Pay attention to the doctype declaration in the boilerplates. 
    • Create a body tag and a 100% width wrapper table.
    • Start out with a 600-640px width, content table. If you have multiple sections (keep it limited), you will have several of these. 
    • If you want to delineate each section with your brand-colors in a 100% width wrapper for better clarity of sections, each of those fixed-width content tables need to be wrapped in their own wrapper tables.
    • Although you set your content tables to fixed width, don't forget to assign flex 100% width classes to them so you can stretch them to 100% device-width in one column on smaller screen-sizes via media-queries (media-queries added inline at the top style section of your email).
    • In your media-query/ies (I only had one for below 640px in my example) you will also style your basic underlined-links on wider screens to work as non-overlapping buttons on mobile (don't forget classes for your link styles even with inline styles specified). Make sure to have enough margin-separation/whitespace so mobile users don't accidentally touch other links due to close proximity. Have your touch-targets large enough for mobile (44px recommended).
    • In case of two columns, they will be just two left-aligned nested tables that fit next to each other within the parent table on non-responsive larger screens but with class 100% flex-width for mobile, they fall one below other on smaller screens. 
    • You can have responsive background-images of multiple sizes for mobile as background images, but I used 100% width images that resized on mobile with the same strategy for optimization that I have used in my previous WVU Research website responsive redesign post
    • Don't forget to run your code through a validator.  
    • Test often on litmus (not 100% accurate) and also send it out to your own multiple email accounts on several webmail and desktop email clients, multiple devices and blast off with the back-up of online version.
    Well, that's about it and I guarantee that if you have to support outlook and, you will be spending most of your time there. Good luck!

    End Result (after responsive redesign)

    This is just a view on browser, which is pretty much what I see in most email clients although browser view not recommended approach to testing as it is not a true representation of how it looks in some email clients.

    Web URL:

    Responsive Views:

    Litmus test results:

    Click to view a bigger image. The unchecked screenshots are just the email clients that don't support responsive emails. It works fine on all the desktop webmail and mobile specific native mail apps and a some other mobile mail apps (eg. gmail app on android and such).

    Here is a quick Polar Poll. Please click to answer (yes/no) and see votes.

    References, Further Reading:

    HTML email campaigns: Basics

    HTML emails/campaigns aren’t anything new, but there are simple, “obvious” facts about it that are ignored by many, leading to their failure and even to complete abandonment of receiving email communications from the sender.

    First and foremost is to keep the frequency of our emails to a tolerable limit. I find it surprising that senders, esp. marketers lose track of this, making us want to hate any email (are these people living in a matrix? don’t they face email overload in their own inboxes?!).

    I find a frequency of once a month to be most appropriate. The more often we see an email the more we seem to be put off by it. Sometimes even the ones that give an option of reducing the frequency still seem to be too frequent! 

    Take a look at a Polar poll below on email frequency and related unsubscribe effect. Vote on your choice to see results.

    When I started our WVU Research HTML e-newsletter, I was a bit weary.

    Given the number of emails we receive, I was afraid this might just be one of those lost causes. But much to my pleasant surprise, when followed up several times with Google Analytics RealTime Live and user flow analysis, following a blast, it was found to increase the website visits to WVU Research portal website by 227 - 180 % on several days following the email blast and showed that users explored the website beyond just the links in the email. 

    It was also refreshing to see subscribe requests by faculty/staff/researchers who were not in the mailing list by default and it also brought about increased interest and participation by faculty and staff at WVU (when I was actually afraid of a slew of unsubscribes).

    Although many of the factors above can be automatically tracked by HTML email campaign monitors’ tools, it is just as easy to send out and track stats with your basic e-mail blasts (via any email client with which you can send out an HTML email) coupled with Google Analytics.

    Sending: With Safari and Mac mail, sending out an HTML email just involves "mail contents of this page" and sending it out to your constituents/list-servs. Many other email clients on Windows also have easy ways of sending out an HTML email.

    Tracking: If you create trackable URLs in your email with Google URL builder you can follow up on the visits to links within the email with the free Google analytics tools. Including campaign info right in your URLs will help you monitor multiple campaigns over time.

    Based on my experience, I think the overall success of any HTML newsletter/campaign has to do with:
    • Keeping your content focused and minimal
    • Lower frequency (don't bombard with a slew of links/offers/info/reminders every other day!).
    • Sending out information that is of value to your users/customers.

      In our case, along with news highlights, I also included funding opportunities, time-sensitive information sent well in advance, featured new equipments in Labs, changes in processes etc. 

      For commercial vendors, including free articles, videos etc. related to the items sold would be good (eg. Photography tips/articles with a camera and accessories vendor). 

    A step up:

    Read about my experience with redesigning this basic HTML newsletter to a mobile-friendly, responsive format.

    Here is the screenshot of the plain old HTML email before responsive redesign:

    Sunday, December 1, 2013

    WVU Research responsive redesign, web performance optimization and more...

    The main purpose of this article is to share my experience and lessons learned during the responsive redesign of WVU Research website and also dispel some myths about responsive design, workflow and especially SIZE of responsive websites with example and proof.

    I am grateful to the openness in web-community in sharing knowledge and information in these exciting times and inspiring others with their work, knowledge and feedback.

    Website link: Please note the version of the website described here (designed and coded by me) is currently only available through screenshots below as the current iteration of the website is different from this.

    Screenshots: On my portfolio page

    Myth #1: Responsive design is bloated and a responsive webpage is generally over a Mb.

    No, not if it is done right. Proof is all through this article.

    Read on to find out how I have managed to have the sizes of home page at ~205K loads in 665 millisecs to 1.5 secs on desktop and 160.52K, 1.29 secs on mobile. Home page and other pages tested were faster than 95% of all websites tested!! According to Pingdom webpage test and mobitest data.

    The feedback has been very good so far, from administrators, internal users and clients on the effectiveness of the website overall.

    See results below:!/cYu2xJ/

    Myth #2: Responsive design workflow is a big hassle.

    I agree that we are still figuring things out regarding process (and more), but we can share and learn from others and adapt what's best for our model. I can even say it has perhaps made things easier and faster in certain ways, more so if you can code.

    More on Responsive workflow:

    Slide decks from BDConf from Ben Callahan's presentation

    and perhaps a lot more I may have missed… Need I say more?

    Myth #3 Responsive design takes too long to create and not a good option.

    As much as the complexities have increased, we have more resources, knowledge and sharing at this time that takes some hassle out of this and makes things easier for designers and front-end developers to create responsive websites.

    If a single in-house designer/front-end developer (yours truly) can create several responsive websites this year, along with other projects, a team can certainly handle bigger and more complex websites. With better workflows, one can cut down time from much of the processes we used to get stuck on earlier and even come out ahead on time!

    Myth #4 Frameworks are bad and is it worth learning Sass?

    Again, not if used wisely. Choose just the components that suit your website and the ones that work well for your UI. Also, just because you choose a framework doesn't mean that you choose every component that comes with it. Modify and customize components based on your needs, UI and UX and add your own.

    In fact, Sass is what helps you keep things modular, smaller, and in order. Read more below.

    To Sass or Not to Sass or better yet,

    Take my word for it and many other converts of Sass, it's worth it... learning and using it!

    Frankly,  it scares me to think of changing things on my previous non-Sass website!!

    I. Background on this project and wireframes

    See details on my portfolio:

    WVU Research website wireframes

    II. My workflow, process

    As with my previous responsive websites, I kept the workflow and process agile which is why you may see UI change somewhat during the process.

    I started out with wireframes which was a big help in communicating to administrators and content folks on information architecture and various content areas. The linked wireframes were especially important in stakeholders getting an idea about the key areas, give their feedback and it took very little time to create.

    After this process, since there is a good idea of layout and content, I get to the code as quickly as possible (in case of new designs, this would also help with content folks getting to work in parallel).

    With the help of frameworks and Sass components, it was really easy to start a functional mockup of basic templates and get feedback from others and adding refinements as I moved on.

    In a situation such as our's (an educational institution, or a corporation) this process becomes quicker as one would have defined style guides, but Style Tiles and more functional styles and pattern libraries would be of help at this stage in other cases.

    The links I've posted on workflow in the introduction section cover a lot of workflow scenarios.

    III. The Fun part: Website coming alive!

    @lukew, Yes, I admit it… Responsive design is FUN! (refer tweet)

    I used Sass along with CodeKit (use any other compiler of your choice) and Sass version of Foundation 4 (latest at the time).

    Typography, variables, global styles, styles for each component, javascript, everything is/can be separated. Read the nitty gritty of these in my Sass post.

    There are many more articles written about Sass to make you a convert. You don't need to use command line or know Ruby etc. and yes, you can also use Sass based frameworks, eg. via codekit (not necessarily as Ruby lib.) and hook them up ever so easily from anywhere on your machine and customize your components.

    Mobile First, Performance Optimization and Testing

    These were not NOT separate steps in the process but were incorporated, intertwined and thought about in each step of the process starting from wireframes (annotated).

    Mobile-first isn't really hard to make it work. Use respond.js or, many frameworks have created specific grids just for their frameworks and it only took me about a day to make it work decently in IE8 with some additional IE8 specific styles.


    If you have to support IE7, sorry, no tips here.

    Having used the functional, coded "mock-ups" I didn't have to create 30 different images in photoshop to show how the site looked in many devices. In fact, it even saved me time compared to previous workflows.

    I did tweak the breakpoints and modify them along the process. I didn't use device breakpoints. Firebreak (a firefox add-on) helped me in refining my content, design based breakpoints.

    I want to stress upon incorporating testing in all phases of the project (coded) and that really saves you much trouble later on.

    Below are some of the basics I started out with.

    You will have many web resources on these which I will not repeat here.

    1. SVG images (eg. the WV branding pattern on the home page was a mere ~4KB v/s a jpg or png image of the same which would've been close to 20K (or more).
      I added *subtle* CSS3 gradients to it to have a similar effect and some dimensionality as a jpg.
    2.  Iconfonts: I used Icomoon icon fonts.
      James Williamson at #BDConf shows you how to create your own icon fonts! (as usual, his talk summarized by Luke W).
      I haven't used it in this project, but Grunticon from filament group has svg icon solutions (with png back up).
    3. Note that in addition to icons in navigation area, I have also used icon fonts as visual reinforcement/imagery on pages, coupled with CSS3 border-radius in several cases (just works with font-size).
    4. For the Find Research page, I started out with the icons from the noun project and customized them. Due to backward compatibility issues, I have used a sprite of all those on that page (with added CSS3).
    5. I started out with CSS only modal windows on the Find Research page (uses JS on IE8) to showcase centers and research in each research field but unfortunately found out that they had several issues on mobile devices eg. The modal windows trigger links underneath them in several cases and had many issues on Kindle Silk browser.

      For my purpose, I found that a content-dropdown worked out better (a component of Foundation 4, works great on all browsers and devices, even on blackberry!!).

    The dreaded carousel:

    Another thing we love to hate, along with Brad Frost but something many of us are forced to use.

    Bottom Line: Don't use it unless you have strong reason to.

    If you do have to, it takes hell of a long time to make captions work for multiple breakpoints.

    Here is a poll on carousels I made on Polar Polls by @lukew click to cast your vote and view results.

    I used the carousel on research website as an enhancement for larger screens to showcase multiple areas of research-focus at WVU, coupled with content related to that (available on all screens).

    It is not displayed on smaller screens, (ideally it should be based on bandwidth and device and NOT screen size), but to compensate for that I have made sure that I have kept the sizes low for any screen size/devices.

    Here are some points to note…
    • I used responsive flex-slider which has many useful features
    • Didn't make it to be auto-forwarding (distracting to users).
    • Made the controls clearly visible and usable.
    • Made content/caption as HTML copy.
    • Made it touch enabled (Caveat: I found out that the touch option doesn't work on HP touch enabled desktop, need to check on that.) 
    • Used randomize option to present all items for repeat visitors. 
    • Loaded only first two images and not all images in carousel by using this script by Erik Runyon.
    • In addition to the above, for the smaller screen cases, when the carousel is not presented at all, I wrapped the above JS in screen.width to not load ANY images on those.

      if (screen.width > 400)
      … carousel images uncomment script


    Here is a similar technique as above by Dave Olsen of WVU for lazy loading and showing/uncommenting any content on a webpage via user action/mediaqueries.

    Foundation 5 also has a new feature, interchange with HTML 5 partials to accomplish the same (haven't used it yet as of this writing).


    During early stages of development I used browserstack's browsers and emulators (via web tunnel when testing on desktop).

    Mobile browser emulators are helpful but only provide a starting point. Can't stress enough on the importance of testing on real devices. Most of the issues that I came across were during testing on devices. Kindle Silk browser and older androids seem to be quite limiting.

    Even if you don't have a device lab or is inconvenient to access, try and gather/involve some devices from your colleagues and test. I did the former in initial stages and tested at our WVU device-lab on a larger set of devices later.

    Tested OK on many versions of iOS, android and even on blackberry (except for icon fonts).

    Lesson learned: We already know this… and I reiterate: Test early and test often (on as many devices and browsers as you can, at each step).

    More notes on Performance

    Optimize web performance and get the size of your webpage as LOW as you can.

    Not everyone is on unlimited data or a T1 line and don't penalize them just for visiting your website!

    Most of you have surely seen innumerable articles on the increase of mobile visitors on all websites. If you want to blow out your mind… check out this list.

    Thanks to Jason Grigsby (@grigs) @lukew and many others at BDConf for inspiring me to do more w.r.t. performance.

    It's been said numerous times (with data) and I will say it again…

    Images account for about 70% the weight of an average webpage.
    Think more about reducing the number and size of pretty pictures on your website before complaining about the size of a CSS framework or JS library.

    Responsive Images

    Frankly, I haven't done much w.r.t. responsive images but rather used alternative and low-tech tactics to keep image sizes low on all (reducing images, image sizes, icon fonts, svg etc.)

    These are some more tricks below I used for lowering image sizes:

    • A basic photoshop "save for web" doesn't cut it any more (only a starting point). I used and other jpg, png optimizers in addition. 
    • I saved 2X images (200%) at 0% quality + optimized (looks terrible in that size) but shrunk it down to 100%, on the webpage, in situ (eg. a 1200X600 displayed as 600X300. This has been talked about at many conferences including BDConf recently. Oct 2013). This gives more than 50% savings on image size. Be less rigorous on photo-based websites/portfolios as the images suffer in quality. 
    • If you have a lot of images, command line batch processing options may be of use. 
    • Simpler images (think shallow DOF), work well and are also smaller in size than busier images. 
    •  If you have too many images and your site is based heavily on images, Grigsby suggests online solutions for hosting responsive images. was suggested by a reader.

    If you've looked at Web Perf tests on pages with embedded youtube videos, you will see big sneaky embeds showing up. Here is an alternative to reducing the size of Youtube embeds which reduces the size by 300k (until upon request for video play). Won't work on IE 8 use alternate embed for IE8 .ltie9 + specific style.

    If you have questions or suggestions and need clarifications on any, please contact me.

    Thank you for reading and hope you learned something new!

    Saturday, July 13, 2013

    Case Study: Using Foundation 3 for redesigning West Virginia University’s Shared Research Facilities website

    West Virginia University's Shared Research Facilities wanted their old website redesigned, to one that worked well on multiple devices and mobile due to specific nature of their users’ interaction with their website and its resources. They also wanted to move the site to WVU's in-house Content Management System for easy content maintenance and updates.
    This case study is based on a previous version of Foundation, but my basic process still remains the same as described here (except for using the Sass version now). If you'd rather learn about my project using Foundation 4, the latest and greatest version of Foundation or learn about Sass, visit these links.

    To Sass or Not to Sass
    WVU Research Redesign
    I had tried adaptive CSS frameworks earlier, incorporating media queries with set breakpoints; Jquery plugins etc. on previous websites and wanted to move on to a completely responsive, device-agnostic solution. Thanks to Luke Wroblewski's (of Mobile First, Bagcheck, Polar app and more) suggestion at An Event Apart conference; I took a look at Foundation… made detailed comparisons with other CSS frameworks eg. and decided it was indeed right for this project!
    Foundation had every functionality I needed, and more, all integrated and so easily customizable!
    Here is an insight to my process. This was my first of this kind, has yielded quick results and has a great potential to be used again!
    More about SRF Project and Web Performance details on my Portfolio
    1. Went through our old website to be redesigned, looked at how the user experience and interface could be enhanced by modifying site architecture, presenting content in a better way, reorganizing, adding interactivity and considered what/how things needed to change on devices. 
    2. Had a quick read through of the Foundation 3 docs, components etc. and compared to other frameworks.
    3. Created first set of lo-fi wireframes after initial meeting with the client (internal) and improvised as I went along.
    4. Based on the plans, wireframes, I selected several CSS and JQuery components I needed. There were a couple of features that I ended up not using later, or added some later as it would happen in most projects and they were so easy to add/remove in CSS and Js, thanks to the nicely commented and organized code. Icon fonts were great; loved the hide-show classes; customizable panels, buttons, orbit, magellan, joyride were very useful for user-friendly, interactive presentation. Navigation was an icing on the cake!
    5. I started out with one of the basic templates from Foundation that was close to my wireframe. I changed quite a bit as I went along, but it provided a quick starting point and good for learning by example. In fact, it was so simple to use, I could learn as I go. Barely any learning curve.
    6. Modified the initial starter template to our needs and it served as a more hi-fi wireframe.
    7. Now for the pleasant surprise!! As many, I generally do a photoshop mock up for approval and feedback from our University web central, and to get design feedback from other designers at the university and then start coding after feedback. Here’s how this changed.
    After the basic functional wireframe, I started playing around with it, customizing the colors, styles, CSS to match with WVU branding and presto, I already had a functional mock up for home and basic back page templates!!  I took screenshots of these (several screen sizes), posted for design feedback. Also gave live test area w/URLs so others could see how the design changes in different screen sizes so having to change each mock up based on suggestions was eliminated!
    1. I was able to incorporate several suggestions from other designers on the fly, and there I was, set with the basic design already coded. I started adding several interactive components as I went along according to my plans. Magellan, Joyride. It also provided a good style set for coding buttons, panels completely with CSS3 as I have been doing.
    2. There were a few short road-blocks which I passed through quickly, thanks to foundation github forum and the google foundation forum. I also learnt, researched a few things on my own which didn't take too long.

      Here are some quirks which may be resolved as
    1. There is a work-around to make panels line up in two per row by making them equal size (see home page panels).
    2. Some issue with Joyride went away when I grabbed the most updated code directly from github.
    3. Strange, but Magellan for some reason wasn't working with the minified version of JS!! and a few other minor issues.
    4. I used a non-js responsive table solution, vs the one from foundation.

       Overall, I completed the project in much less time than my previous web-projects, (between other projects in parallel) by combining the mock-up feedback and coding process and designing in the browser.
    Single in-house designer-developer.

    What about Internet Explorer?

    This works well up to IE8 and somewhat clumsily on IE7. It was ok for our requirements of this particular website. I have conditional comments for older browsers to download newer versions.
    I was thrilled by how much more improved the Foundation 4 is, especially the Sass version, mobile-first grid better semantic markup and streamlining of its features. Don’t miss it!!


    I have basic performance optimizations in place (minifying CSS, JS, reducing http requests, compressing images etc.) based on web performance tests. There is scope for more as browsers and standards evolve. I have designed and coded the site to be both responsive and responsible as the stats below show.

    As of this writing:
    Webpage test stats to be about: 489K (1.7-2.6 secs) for Home page!!
    Mobitest stats show download time for home to be about 3.3 secs, and a sample back page is about 2.8 secs (233K).
    Obviously, it is on the lower end of the responsive site size spectrum, as I have tried to keep the overall size of the site small, whether desktop or mobile. reducing the size and number of images and the overall size of the website by using CSS3 to replace any images that I would've otherwise used for page elements, icons etc.

    Optimizing site for mobile is good, but why should we assume that desktop users have all the time and bandwidth in the world and serve them a huge site with something that we think isn't truly essential? Optimizing for desktop, IMHO should be more about the specific functionality aspects than just bigger images/layout. Vice versa holds good too in assuming mobile users don't need something that desktop users have. Trying to use a true mobile first approach by making the site keeping the the most essential content and functionality required for any user. I am looking into the carousel stats and feedback too.

    Wireframing for Web, UI, UX design

    I see a lot of questions in forums on, “to wireframe or not to wireframe?”; which wireframing tool to use? etc. While things can be different based on the nature of your work, your needs, projects etc., here’s something that worked for me, which I shared recently with my colleagues at West Virginia University. It can work for you, even if you are not in higher-ed.

    A wonderful tool called Balsamiq (no, it's not a typo)!
    Here is my review of the desktop version of their product called 'balsamiq mockups' that I am using, the other versions have similar functionality. They provide a multi-user, monthly, cloud based option and other plugin options too.
    It is free for non-profits and educators, but not for staff in higher-ed, although you may qualify in some ways.

    What is Balsamiq?

    Balsamiq is a lo-fi (only in looks) but highly functional wireframing tool that lets you create wireframes/lo-fi mock-ups using many readymade UI components, quicker than sketching or in photoshop (yes, even with ready psd UI components), and the best part… make them clickable (ooh!), link them to each other, even without the cloud based model (aah!).

    Why Wireframe?

    • Let’s look at a scenario: You present the clients (internal or external), a sitemap/site architecture with all the sections, connectors, flow diagrams and what not; perhaps some sketches; a bunch of photoshop mock-ups; explain everything and I bet you still see some confusion during review, content posting (CMS), testing, about which content goes where, why we did this, etc.
    • I think, when clients see fragmented pieces of a website/UI model, they may have a hard time putting it together after a while, as they aren’t always working on these as we designer-developers are.
    • With linked wireframes, clients can focus on key elements of webpages, functionality, user needs, goals, interface, user-flow w/out getting bogged down with colors, design etc. (you are there to take care of those!). They like the “clickable” aspect, as they can see a quick working model of the key areas/features of the website/app.
    • The responsive workflow: We all love photoshop, but as much as we may hate to admit it, the regular photoshop mock-up workflow isn’t cutting it these days with responsive web design. Many of us are probably already trying different things, without even being aware of it ourselves. eg. I will soon post a link to my recent experiment on a modified workflow here.
    • Wireframing, Styletiles, and now even interactive styletiles, CSS frameworks etc. are getting to be a big help to many of us with the new workflow/process. They are helping me and perhaps many others even "design in the browser" (yes, it isn’t really as shocking as it sounds), more so when you have a specific set of style-guides, color, branding and custom styles/rules for your University or Corporation.
    • It is quick and efficient! chop chop and you are done!

    What do I like about Balsamiq?

    1. The lo-fi sketched look but hi-fi functionality which is very conducive for quick and good feedback.
    2. Simplicity and ease of use. Just like Photoshop… All the familiar shortcuts and tools you are familiar in photoshop: Zoom-in and out, ctrl-tab to move between docs, group, ungroup, lock, align, distribute centers, smart guides, grid and more, so you don’t have to learn one more new thing, when you have so much new to learn already!
    3. Here are some of the key features that I liked in balsamiq:

      • Great UI library, made even easier by 'quick add'. Start typing browser or button or navigation or icon etc. in 'quick add' input box and it will 'read your mind' and show all options! Just hit enter and customize.
      • Icon library.
      • Datagrid.
      • Mobile UI components.
      • Just start typing 'Lorem' and it will do the rest! Well of course, you can type in more descriptive content when needed.
      • 'Mock-ups to go': Sharing components, controls and GUI elements. You can make additional components and share or use the ones that others have created and shared (think symbol library).
    4. Great user-centered customer service from a conscientious company; a ton of resources and support forums.
    5. Best part… You can link between mock ups and even bundle/package the whole project into a single pdf with a group of interlinked files and send it over to clients or share it on dropbox etc.
    6. By the way, they have gotten rid of Comic Sans in the wireframe and use 'architect' font instead now, so breathe easy!
    They (I mean the balsamiq folks, on their blog) even help you figure out what’s for dinner (not cook, though). Unfortunately no help with your taxes yet!!
    Here is a link to some wireframes I have created using balsamiq (note that the linking between wireframes only works with the linked pdf document).

    Friday, July 12, 2013

    To Sass or Not to Sass?

    First things first. If you are looking for advanced tips and tricks on Sass, to know everything about it, you might want to look elsewhere… like some of these articles listed here and a ton of others on the web. Some of these also talk more about cons, things to keep in mind etc. esp. the one on Lea Verou’s blog and one from CSS-Tricks.

    Who is this post for?

    If you are someone who has heard about Sass, kinda like it, not sure if you want to start learning it, since you have a ton of other new things to learn on your plate already, and want to hear from someone who has just made the leap into learning Sass, yes, this is the place.
    Also, this post is not just about Sass, but more of how I incorporated Sass into my current project, things that made learning it easy (for my style of learning) and more fun.
    To make things easy, Read/Do PART II only after you’ve read/done the suggested things (reading list) in Part I. It won’t make much sense otherwise.

    Let me jump right in with some points/pointers in order.

    PART I: Say hi to CSS pre-processors (Sass here):

    1. It might not be the best way to start learning or trying to understand Sass by getting on the main Sass website. Try the other websites first, starting with basics and experiences from people I have listed on the top.
    2. What is Sass in simple terms: I think of it as “CSS shorthand” … Writing CSS in a terse format, nesting selectors the way things make sense, using variables for the things you repeat (think of your brand colors, typography elements, media query breakpoints and more), keeping all your CSS for specific items separate (for some of us “monks”) but still be able to bring in only the bits and pieces we want together (@import) and then compiling it so it outputs CSS as we know it. Ooh compiling, command line… I am outta here… No stay with me… cue in some super-woman music and enters this amazing little software called CodeKit (more recently and others do similar things, but I haven’t tried that).
    3. Yes, CodeKit makes Sass and playing with Sass and frameworks just SO MUCH FUN! Compiling, command-line, Fuhgeddaboudit! It does it all for you. More about it later. Oh, btw, that’s just for Mac and there might be something called Scout app for Windows, I think works on windows as well. May be some others too. Check it out.
    4. Addendum: If you'd rather stick with CLI workflow, checkout Node JS with Grunt workflow.
    5. OK, sounds good, how do I start?
    6. Get a general idea about CSS pre-processors and Sass from the few links listed on top, read some basic articles, video tutorials if you wish, but don’t linger too long with nitty gritties to make you want to give up! Get an idea of mixins, learn about Compass, but you don’t need to start using compass right away. Baby steps if you’d like.
    7. I am guessing you’ve already decided on on which “flavor” of CSS pre-processor you want to use i.e. Sass (.scss) vs LESS. If you are not sure, to make it easy on you, I’ll say Sass, but if you want to find out for yourself, read this

    PART II: OK, how do I really start? 

    1. Get CodeKit (or or whichever software you’d like to use to make compiling easy). Of course you have just the straight command-line options as well. Read about CodeKit and how it works. It is more than just a Sass compiler. It concatenates, minifies your files and even reduces your image sizes further (like or such).
    2. You are gonna need a fancier HTML editor than Dreamweaver… this is no WYSIWIG stuff! I went for Sublime Text, go for what ever floats your boat.
    3. Now just get started on a project. Huh, but I am not ready yet!! Yes, you are. If you still aren’t sure, start on a smaller one.
    4. If it is possible to use a CSS framework in your workflow, it’s the easiest way to learn by example. Get a framework that has the Sass version. I chose Foundation 4 by Zurb and it is awesome! You can see how they’ve used variables, mixins, best practices and learn compass too if you wish and by the time you are done with the project, you’ve also learnt the basics and more of Sass.
    5. Gone are the days of having to “customize” the framework and select only the components you need and still having to look at 100s of lines of code in your CSS if you have to edit something. With Sass, you just import the pieces you need for each template (home, back page etc.). Once you point your project to the framework in CodeKit, it finds all your imported Sass files for you. You don’t even need to specify paths for it, CodeKit just knows. Just watch this…
    7. Now for something even better, if you have to customize a certain file a lot eg. _global.scss or _type.scss to fit your branding, leave those files alone in the framework folder and put a copy of those, with the same name in YOUR PROJECT Sass folder and customize all you want. CodeKit will first look for files in your Sass folder and then look in the framework folder.
    8. If you are customizing just a few things, just over-ride them in your home.scss instead after @imports where you are importing all Sass goodies.
    9. Remember, CodeKit concatenates and minifies all other .scss files and CSS for you and outputs a CSS named differently from your home.scss (with a suffix etc.) so make sure you are linking to that CSS file in your html file etc. (after this step it is just your basic CSS and HTML). Yes, this has to be all done locally and it may be hard if your CSS/Sass is edited by a team. Chris Coyier talks about it in one of those links.
    10. Codekit also concatenates JS files and minifies it. You can get several levels of minification. With JS, I find it the lowest level is better as some scripts don’t work with minification (make sure you have back-ups).
    I’ve talked about variables, mixins @import, ease of using frameworks and more to inspire you to use Sass, but wait there’s more…
    I can’t conclude without talking about the live refresh in CodeKit. Make some changes in your Sass (probably a bunch of changes, even better) wait, don’t hit save yet, Keep your browser window open on the side or other monitor (your project folder that CodeKit is “watching” for changes. As you would know from CodeKit docs, it only works with webkit browsers). Now hit save and see the “instant magic” in the browser window!!

    This is just meant to be a pointer or starter or inspiration for using Sass and in no way a full guide/workshop or "how to"s on Sass. Hope it inspires you to use Sass in your next project.
    Here is my first project, using Sass with CodeKit and Foundation 4 Framework, and yes the wireframes in the beginning werer created in Balsamiq.

    Some websites in higher-ed that I admire for their usability, design aesthetic and use of technology

    My Design Sensibilities

    My design sensibilities and ideology can be best summed up in the words of these great designers. As many of us, I may not have completely achieved these in the past, but my goal is to embody these in my current and future work and I find it refreshing that the current trends (and I don’t mean “flat design”) in web design seem to be on a similar path as well.
    Minimalism is not a lack of something. It’s simply the perfect amount of something.
    Nicholas Burroughs
    Simplicity is not the goal. It is the by-product of a good idea and modest expectations.
    Paul Rand
    We don’t get hired to make pretty things or win design awards. We get hired to solve business problems.
    James Bradley
    The problem contains the solution. Michael Beirut

    I think of good presentation/design as not something that just looks pretty/fancy or flashy but one that is aesthetically pleasing with good use of white space, typography, hierarchy, while conforming to web usability, accessibility (especially important in edu sites) and to new knowledge and developments in the field. These websites offer creative solutions to challenging issues particularly encountered in mobile and desktop.
    NOTE: I am not the designer, developer of these websites, just an admirer and a learner.
    As you may notice most/all of these are responsive websites, optimized to various screen sizes: desktop, tablets and smart-phones.

    Carnegie Admissions website
    • Highlights their main features without the use of a huge auto-forwarding carousel (which are known to have several usability and performance issues based on latest data). Also the previous and next buttons for features are clearly shown to explore more, although they could be a bit more prominent.  
    • Great use of space in back pages with prominent and clearly defined headers embedded within great visuals serving two purposes, conserving space and to define the feel of campus with relevant graphics.
    • Responsive website; Scales well on all screens; Search is prominent and clearly defined to chose CMU or admissions site. FAQ, status and contact are easily available on top.
    • I like the ‘tag it’ feature to bookmark pages while browsing and to go back to them for review.
    • Social media shares are always available while scrolling. I wish there was an Apply now button included in the same way, available right when needed.
    • Good contrast and buttons nicely optimized areas for touch targets. The font-size in the copy could be larger esp. important for mobile.

    Information Services at MIT

    • As we know, IT websites have the challenge of having to handle a huge amount of content and information to varied groups of users and this website does a great job of presenting such a scenario in a clear and non-confusing way, delineating by color, typography, icons and even gives an option of audience based navigation in the footer. It also handles the dropdown menus very well in the desktop site, narrowing down the options right within content area in the mobile screens.

    Boston University Today (their news website)

    • I love it when websites that handle large amounts and varied types of content do a great job in making the website look simple and uncluttered.
    • A great balance of visuals and copy.
    • Great typography and hierarchy and use of white-space which hits the sweet spot to make each section stand out very well.
    • I like that the main image is not a carousel/slideshow and doesn’t take up humongous amount of space but offers to view more of those.
    • A beautiful understated, minimal and very well done design and layout! The light colored theme helps maintain the minimalistic feel and clarity.
    • Didn’t Like: Light blue in links is not a good color for readability (Jared Spool on usability) and it is better to use a much darker blue for links.

    Stanford’s Do Research Website
    • Having worked in the research office, I love how the website has consolidated the most common administrative and financial aspects encountered by researchers and presents a large amount of content in a non-overwhelming way with well defined and clear areas to expand content… Progressive disclosure in the right context is good (users get overwhelmed by too many choices presented all together).
    • Love how the most important, funding and contact area is clearly visible with good white space and separation as are the tabs with How to etc. items
    • Good use of breadcrumbs on the back-page and I like how it shows check boxes to show relevant content for the user in context.
    • Didn’t Like: I am dinging points for low contrast in the top-nav which is not good for accessibility (although it becomes clearer on hover) and the pop-up image-content light box is not fully readable on tablet. I can suggest a better responsive lightbox.

    Great content and digital publishing

    Engaging Content

    The Duke research website, is one of my old favorites for great engaging content on a website providing a variety of options in multi-media content for the user… videos, slideshows, blogs, features and even faculty blog-rolls for the users to explore. Although it can improve upon its design, I love it for its variety and engagement.

    Digital Publishing

    With the future of print magazines questionable, Journalism Students at University of Oregon have shown to be early adopters by making the plunge to Digital Publishing (starting several years ago) and have created a digital magazine of their own with engaging digital multi-media content (not pdfs embedded on web) by collaborative effort of senior students working together as their class project. I had an interesting discussion with their professor and learnt more about their process. This is created as an interactive ipad app with a collection of a set of magazines created by the students each year/semester and is done completely in the Digital Publishing Suite (DPS) of Adobe Indesign.

    Boston Research Magazine

    Boston Research Magazine has another take on making the magazine responsive and web based v/s the ipad app approach of University of Oregon.

    • Note: I specifically prefer the 2011 magazine layout v/s the 2012 as there are several accessibility issues (low contrast) in the 2012 version: The main image in that issue being a bit overwhelming, taking up a lot of real-estate on the desktop version of the home page.
    • A great desktop and mobile solution combined into one good responsive website. Great use of typography, hierarchy and color for delineating their content. Good graphics.
    • Scales well on mobile.
    • I like how the navigation is at the bottom which is known to be ideal for mobile and also works great on desktop making it quicker to get to.
    • Good clear hints for side-ward exploration of more articles (arrows).
    • Didn’t Like: Copy needs to be bigger for accessibility reasons and on mobile.