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:
http://mobitest.akamai.com/m/results.cgi?testid=131121_95_Y3
http://tools.pingdom.com/fpt/#!/cYu2xJ/http://research.wvu.edu
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:
http://www.lukew.com/ff/entry.asp?1583
http://www.lukew.com/ff/entry.asp?1353
http://www.lukew.com/ff/entry.asp?1808
http://www.lukew.com/ff/entry.asp?1809
http://www.lukew.com/ff/entry.asp?1394
Slide decks from BDConf from Ben Callahan's presentation
https://speakerdeck.com/bencallahan/prototyping-style-2013-breaking-development-nashville
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, http://alistapart.com/article/why-sass
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.
https://github.com/bradfrost/patternlab
http://bradfrostweb.com/blog/post/atomic-web-design/
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.
eg. https://gist.github.com/hatefulcrawdad/5068210
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.
- 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. - Iconfonts: I used Icomoon icon fonts.
James Williamson at #BDConf shows you how to create your own icon fonts! http://www.lukew.com/ff/entry.asp?1806 (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). - 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).
eg. http://research.wvu.edu/research_resources - 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).
- 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
}
Updates:
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.
lazyblock.dmolsen.com
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).
Testing
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.
http://www.lukew.com/ff?tag=metrics
Thanks to Jason Grigsby (@grigs) @lukew and many others at BDConf for inspiring me to do more w.r.t. performance.
http://blog.cloudfour.com/author/jason-grigsby/
http://www.slideshare.net/grigs/mobile-first-responsive-web-design-bd-conf-oct-2013
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 Kraken.io 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. https://responsive.io/ 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!
Thank you for sharing your experience!
ReplyDelete