With the increasing advent in SOA and RESTful based applications, all the business logic today is being pushed to the client. With numerable paradigms being present for the UI to consumes these services and create dynamic content, there becomes a need to define the presentation, structure and behavior of the User Interface.

While working with Brian Flanagan on a recent project, we came up with an architecture presentation to address this need, with an intent to help the business, customer, stakeholders and development team understand the architecture of UI/Front end development. 

Presentation Layer

The Presentation Layer is mainly composed of CSS components, based out of an atomic design or BEM methodology. The CSS is typically written in either SASS or LESS (today’s most popular CSS pre-processors) and compiled to provide modular, scalable components, which is used to create the structural layer.

Structural Layer

Here, we create the html components/pages for the application, by making use of the structure today’s most popular frameworks provide – bootstrap, foundation and others, depending on the organization needs. The required user interactions are enhanced by making use of a JavaScript library, typically, jQuery. These HTML pages are then thoroughly tested for responsiveness, browser compatibility and accessibility. 

Behavioral Layer

The behavioral layer introduces the business logic for our UI by consuming the RESTful services and creating dynamic content. This could typically include two-way data binding, ajax, MVC and Single Page Applications, all rendered on the client.  There is an increasing number of frameworks to help us work with the business logic and the most popular one’s are Angular, Ember, Backbone, ReactJS among others. Note that selecting an appropriate framework is a very important task as each framework has its own pros and cons catering to different needs. 

Production Layer

Finally, we have a bunch of fantastic build tools that takes care of all the routine tasks involved in development such as compiling, minifying, compressing, package management, among others. The build tools keep a track of changes in all of the above 3 layers and eventually provides us production ready HTML, CSS and JavaScript assets which can now be integrated with any backend application.

I hope this article explains the UI architecture and the underlying processes. Is this something similar you have seen implemented in your project/organization ? Are things being done differently or do you have another perspective on this ? Do let us know below.

Many a times, when I start a new project, often the client gets excited when the word ‘bootstrap’ or ‘foundation’ comes around during the inception phase. They want to know more and get excited. They hope that their site would look great if is it built with a framework and typically look towards the UX developers/designers for advice and recommendations.

Listed below are the benefits of a CSS framework, which can help to educate the client on why they need it:

Responsiveness

The biggest advantage of a CSS framework is the grid system it comes with, which provides adequate breakpoints for different devices (phone, tablet, desktop, large screen), making your site truly responsive for different device widths. If the client persists their site need not be responsive, it is easy to disable the responsive feature for now and make use of the other benefits it provides. This way, if the site wants to be responsive few years down the lane, the foundation is already there in the form of a framework and should not be a hard task to make it responsive again.  

Uniform Styling & Branding

A CSS framework typically provides a uniform structure and styling for all the different html components such as buttons, navigation, panels, lists, etc. This is extremely useful and makes it easy for the design team to look up to and create the branding/styling of the site’s elements based on the framework’s styling. If there is no visual designer in the project, then the framework is already providing a base level of branding for the new site to be built.

JavaScript Components

Every website today makes use of several JavaScript components such as modal dialogs, panels, accordions, tooltips, carousel, etc. Traditionally, without a framework, one would need to write or import a custom JavaScript/jQuery plugin for each of these components. The downside of this method is that, some of the plugins can become obsolete and with no proper documentation or support, it is hard to debug and customize. Today, most of the popular CSS frameworks (bootstrap, foundation, skeleton, etc.) come packaged with these JavaScript components and makes it easy to implement, debug and customize.  

Accessibility

Accessibility is increasingly becoming an important feature of a website. The emphasis is on front end developers to at least provide a base level of support, and one could refer to section 508 checklist for that. Popular CSS frameworks like bootstrap and foundation do already include adequate support for accessibility in their html elements (form elements, modal dialogs, tooltips, panels, images, etc) which a front end developer can use and leverage upon to make the site more user-friendly.

A CSS framework also provides many other advantages such as native support for pre-processors (sass, less), customization for different needs, extensibility, ease of showing/hiding content on different devices, to name a few.

Here is a list of the most popular CSS frameworks currently being used in the industry – 

• Bootstrap
• Foundation
• Skeleton
• Semantic UI
• Pure
• UIKit

It is also extremely important to select the right CSS framework for the application you are building. Because, once you select a framework, it is a big overhaul to migrate to another framework and not advisable. Some of the deciding factors in selecting a proper framework would be –

1. Browser compatibility
2. Learning curve
3. Ease of customization
4. Ease of integration with the backend application
5. Ease of migration to newer versions
6. Usage, development community and support 
7. Number of open issues with the framework 

What is your preferred CSS framework of your choice ? What factors do you consider before choosing one and how do you advice the clients on selecting the right one ? Let us know below.

Programmers, whether novice or professional, encounter roadblocks and issues every day while working with code. This can lead to unnecessary frustration, hamper productivity, and pose a threat to reaching the product deadline.
The following are a few measures that I, as a front-end developer, have developed to overcome roadblocks while working in fast-paced environments with stringent deadlines:
1. I am setting up my developer workspace. It is working for him but not for me.
Setting up a workspace can be one of the most tedious or scary tasks a developer encounters when he or she starts working on a new project. Set aside ample time for this, and do not be scared by the heavy stack of technical documentation. Follow each step meticulously, and make sure you have all the pre-requisites setup. Do not hesitate to take the help of a peer or your team lead if you come across a issue – be it simple or complex. Ultimately, having a proper workspace is the foundation for all the great work you are about to do on the new project.
2. My code is not working or it’s throwing up an error.
We encounter this issue almost every day. We would have gone through the requirement, analyzed the dependencies, made sure the functionality is there, and still the code does not work. Rather than simply blaming the code for throwing up an error, it is best to investigate why it is doing so. Check the browser console, error logs, stack trace. Often it could just be a spelling mistake or a syntax error causing the issue. Have a peer or your lead look over the codebase. A second eye helps in most instances. Do not lose hope, get frustrated, and start cursing your job or the client.
3. My jQuery on click function is not working.
As a front-end developer, you would be dealing with a lot of jQuery, and this issue is something we come across quite often. The blame is blandly put on jQuery or the browser itself. Rather, make use of breakpoints in the JavaScript console of your browser. Check if the code has been rendered on the page and if there are any errors in the console. Put appropriate the breakpoint and examine each step. A div id might be missing, could be a syntax error or even a missing semicolon. Breakpoints are your friend when it comes to javascript errors. Make use of them.
4. Clear browser cache.
We know this, but don’t do this. You have made change to a CSS file, and it is not reflecting on the browser. Always remember to clear your browser cache (It’s easy: Just press cmd+shift+del on your browser, check cached images and files and click Clear browsing data) for any new changes to be seen on the browser.
5. Know how to Google for error.
So you have checked the console logs, made sure there is no syntax error, cleared browser cache and still something doesn’t work – end of the world! Not really, as long as there is the Internet to help us out. Someone would have encountered this already and might have put a solution or the issue could be a well-known one. One important thing is to make sure how to make the best use of Google to help us fix errors. Search for the errors with meaningful phrases, such as ‘jQuery works in console, but not in code’, ‘bootstrap modal dialog function’ rather than simply searching for ‘jQuery is not working’ or ‘modal dialog issue.’ Another helpful measure is to search with the exact error message thrown in the console or error logs and often this might help us find a solution quickly.
6. Take breaks, and do not multitask.
Take adequate short breaks at regular intervals to regain your focus and keep up the concentration. If you have been looking at your computer screen for too long and you encounter an issue, chances are that you would end up stressed out or frustrated and lose focus. Hence, taking breaks is important. Secondly, we all think we can multitask, switch between different windows while drafting an email or checking one. We are actually not multi-tasking here. Rather, we are shifting the focus of our brain to different jobs in short intervals of time. This is bound to make you stressed out after a while and leave you feeling tired. It is best to focus on one job at a time, complete it, and then move on to the next to increase your productivity.
I hope these measures help you mitigate a roadblock when you are working with code every day. What are some of the measures you have been following? Share them below.

Recently, I was reading this article which came across my newsletter, outlining what Front end developers need to know for this year and beyond. What struck me was where the author talks about the growing gulf between those who focus on CSS and those who focus on javascript. Isn’t Front end development about both css and javascript? Lets not forget html! But what’s been mentioned is indeed true. Here is how I tend to see this pattern.

I started my career as a web developer and my daily source of bread involved taking a psd asset, slicing and dicing it and creating pixel perfect, browser compatible html and css using cool jQuery plugins to beautify the UI. And that’s where my interest towards javascript began. I got to know the basics, understood the different paradigms, kept track of its progress, introduced to the MV* frameworks, got to know node, the build tools, pre-processors, et al.I would say many of us peers share a similar career path. 

But there is another set of front end developers (or what do I call them) who solely focus on javascript and thanks to css frameworks (bootstrap, foundation, etc), writing css has never been so easy. They need not know the intricate differences between css2 and css3 nor how different browser engines interpret the css box model. They need not even support IE8. They are skilled and adept in the javascript MV* frameworks, node, the different build tools, good enough to create a web application. 

These two different breeds of front end development raises some very interesting questions. How should the former advance his career ? And should the latter fall back to learning basics of creating pixel perfect sites ? Or are there two different sets of Front end developers now ? One solely focusing on creating pixel perfect html, css and js while the other focusses on MV* frameworks. How should the corporations decide on hiring whom they need ? 

I personally feel if you are from either group, it is still important to know the basics of any fundamental technology you are working on, think from a broader perspective and be inclusive. What do you think ? 

A lot has been talked about client side view templates hindering the critical path, thus affecting performance. I have made an effort to summarize the need for client side rendering and measures to enhance the performance.

Before we actually jump on to measures, lets revisit how today’s web application ended up being rendered and compiled on the client (browser) using javascript based templates –

Before the advent of nodejs and javascript templates, how did one used to render json data on the browser ? 

Front end developers (FED) used to write prototypes based on html, css, jquery and hand this over to the backend developers. Backend devs take this asset and integrate it with the java code, parsing the json themselves directly in the servlet or jsp. Here, it takes only one call for the page to load and FED can focus on optimizing critical path, gzip the assets, etc thus improving the performance. This really worked well when we had only one or two FEDs for the whole project and a waterfall approach was followed. Designers used to provide the comps, UI developers created pixel perfect prototypes, and no design changes were allowed once the development started.

And then, what happened ?

Coming back to where we are today, as the web evolved, more focus is put on User Experience, and with the introduction of LeanUX, design and development are being done simultaneously. Now, backend developers cannot change the html in the jsp or servlet every time the design changes and becomes frustrating for them and they don’t see the need to do that at all. Enter jQuery and ajax. FEDs can make an ajax call to the RESTful service, parse the json and render it on the presentation layer, i.e jsp. But, this resulted in a convoluted mess of spaghetti code and became hard to maintain as the application grew. 

Same time, javascript became more mature and nodejs was introduced.  With the help of nodejs, enter client side templating – handlebars, mustache, htmlbars, etc. These templates are logic less (no if, else, for loop statements in the html) and provided a clear, neat separation of html and data paving the way for a true MVC architecture on the client. Both front end developers and back end devevelopers are happy as FEDs can focus on neat reusable, DRY html with dynamic data while backend developers can focus on generating the RESTful API service, data binding and need not worry about design changes at all. Because, data parsing is completely done on the browser now. To help with this data parsing and templating for the FEDs, a host of task runners to improve performance, based again on nodejs got introduced – grunt, gulp, etc. So that, FEDs can focus on the html and the task runner can do all the performance optimizations for them. Wonderful, isn’t it ?

So, what is the disadvantage of this client side templating ? 

With client side templating, every ajax call we make, there is an extra http call on the browser, and the template has to parse this data as well as render itself on the browser. Enter performance issues and critical path rendering.  

How to remediate ?

Fallback to nodejs for solutions again. Client side templating is still fairly new and as the web progresses, definitely the focus will be on ways to render the data on the server itself. There is already htmlbars, which is out to do that as mentioned here, here and also here.

Ultimately, the advantage of separating html from the backend code and allowing front end developers to make robust design changes concurrent with the development cycle has proved more advantageous, than the performance issues with the client side templating.

A colleague recently asked me to give him a high-level overview on how to get started using these fancy front-end build tools everyone’s talking about. Since I’m a team player, I thought it would be best to share my advice with all of you as well!
First, what the heck am I talking about? What are “front-end build tools”? Simply put, there is a community of people and a whole bunch of services out there who just want to make it easier for front-end developers to build projects. Their motivation? Why go through the hubbub of setting up your working directory structure, downloading the plugins and libraries you need, writing scripts for minification, etc., when all of that can be automated?  Enter the realm of build tools.
Now that you know what they do, how do you use them? I fully support the idea of learning by doing, so my job here is to introduce you to your new friends, and let you guys get to know each other on your own time. Have fun!

Node.js – https://nodejs.org/

First things first is Node.js. Node is the foundation for any front-end build tooling you want to do.  Many, many blog posts could be written on what Node can do, but for our purposes, it’s a means to use NPM (Node Package Manager) which you’ll use to install all the other things.

Grunt – http://gruntjs.com/getting-started

Grunt is a task runner that lets you automate a lot of your development process (minifying scripts, compiling SASS, watching for changes to files and reloading your page for you, etc). There is an alternate tool called Gulp that is gaining traction, but I still find that Grunt’s community is larger and better supported.

Bower – http://bower.io/

Another package manager that will download any assets you want / need for your particular project.  Most build tool generators will use Bower to get you set up.

Yeoman – http://yeoman.io/

Yeoman let’s you skip learning all the intricacies of building a Node / Grunt project from scratch and just use a build tool someone else already wrote.  Install Yo, then head over to the generators page (http://yeoman.io/generators/) to find one tailored to what your project needs are.

The appeal of build tools is that they should make your development process easier.  Yeoman and Bower make setting up your project at the start quicker, and Grunt makes your dev process easier throughout the life of your project.  You’ll excel if you really dive into Grunt and learn all that it can help you do. No task is too trivial!

And that about wraps it up. Get out there and start automating!

Below are some of the basic important techniques a front end developer could start incorporating right from the beginning, into a project that has to conform to WCAG 2.0 standards.

Hierarchical Heading Organization

Make sure the headings on every page of the website is in an hierarchical order, beginning from h1 to h6, properly nested to facilitate navigation and understanding of overall document structure. This will allow screen readers to announce the text as a heading with its level, navigate to the heading markup, thus allowing users to quickly find the content of interest.

Appropriate tab-index

Users should be able to easily navigate the website and access all the elements using keyboard tab key. Tab through all the elements of the webpage after it is developed and check if all the elements can be tabbed through in the manner intended. Double check this functionality for form elements.

Add ‘skip to content’ functionality

This is extremely important when users are accessing the site using a screenreader or navigating the site only with a keyboard. The user need not navigate through all the navigation items before reaching the main content every time they visit the page. An easy way to implement this is, when the user visits the site and hits tab, a ‘skip to content’ link should appear and on pressing enter key, should take him to the main content. If the user wants to scroll through the navigation, he can simply press the Esc key when the link appears. A neat example of this implementation is provided here.

Add screen reader only and aria hidden class

Certain elements need not be shown on the screen reader but rendered only on desktop, and to achieve this add the ‘aria-hidden=true’ attribute for those elements that need to be hidden from the screen reader. Same way, some elements need to be displayed only on a screen reader and to do this, refer to the css framework your application is using. For bootstrap, adding ‘sr-only’ class makes the element visible only on a screen reader and in Foundation, it is the ‘hidden’ class.

Alt attribute

Add ‘alt’ attribute for all the images and visual content used in the website. This is extremely important for screenreader to identify visual content.

Add aria-labelledby and aria-describedby appropriately

Use aria-labelledby attribute to identify the element that labels the current element. This attribute can be used to associate an heading with a region, or to provide multiple labels in a form. A detailed explanation with appropriate examples is mentioned here.

Use aria-describedby to identify the element that describes the object. For e.g., if you have an anchor element on hovering which, a tooltip is displayed, use aria-describedby on the anchor element with the value being the tooltip content. 

Tools and Plugins

Use JAWS for the screenreader, mac OS X voiceover feature, firefox wave toolbar and chrome’s accessibility developer tool plugin.

Adequate User Experience, proper sprint planning, level of conformance

It is also extremely important for designers to keep accessibility in mind while designing the User Experience. Finally, check with the organization on what WCAG level the website should conform to. Read through the guidelines, add them in the sprint planning, let the stakeholders know and implement accessibility measures right from the prototyping stage.

Looks like the folks over at Wired launched a redesign of their site yesterday.  I was just reading through an article about it written by their engineering director.

http://www.wired.com/2015/03/wired-dot-com-from-the-devs/

I’ll let you creative types comment on the actual design of it, but there are some interesting things they are doing developmentally that strike my…interest.

First, they appear to be using Flexbox, which is an awesome layout tool, but won’t really help you if you need to support older versions of IE.  I’m glad to see a large company taking the plunge and using modern practices to take the web into the future and not being held back by older browsers. I wonder what their browser usage stats are; speaking with Perficient XD’s Manny Muriel, he made a good point:

That is interesting that they are using Flexbox. I just tried their site out on IE8, and it is completely broken. Maybe the amount of hits from old IE are too few for them to care anymore.

It’s a bold move, but it’s what we front-end developers like to see. If you don’t need to support out-dated browsers, don’t do it!

They also claim to have done some extensive tweaks in regards to performance and cut their page load time by half.  I’d like to take a more in depth look at what exactly they’ve done, and how similar tactics could be applied to our client projects. XD is pushing performance this year, and this seems like a good case study.

The way they handle link underlining is intriguing as well.  Not just your standard text-decoration: underline, and it makes for a neat experience.  There’s a write-up about how they did it on Hyungtak Jun’s blog.

Thoughts? Leave a comment with what you think of Wired’s site redesign.

In the technology industry, we often take for granted things in our work routine that we do so often we don’t even realize we’re doing them: keyboard shortcuts, program macros or any other “muscle memory” tasks that are second nature to us.  Many a time I have found myself working with a partner or helping a coworker with a bit of code and they stop me with a, “Whoa now, what the heck did you just do?”  For those people I’ve bullheadedly helped without helping, here is a short list of things you might not have known you could do with Chrome DevTools.

Android Debug Bridge

For starters, a few years ago I wrote a two-part article on how to use the Chrome DevTools to inspect and debug webpages from an Android device.  Pretty cool stuff, and useful when developing a responsive web design.

Force Element State

Another helpful feature is the ability to force states on any particular element in the DOM.  Do you need to debug the :hover styles of your main navigation, but can’t just leave your mouse hovering over it?  Pull up the DevTools, right click the element in question, then go to Force Element State.  You can have the browser mimic :active, :focus, :hover and :visited styles on any element.  This simple feature saves many a page reload.

Forcing an state on any element is just a right click away

Color Picker

The DevTools also have a color picker built into every CSS attribute that accepts a color value (color, background, border, etc).  In the Styles pane, right next to your color value it will show a small box that is filled with the color value you’ve specified.  That in itself is a handy feature to show you exactly what you’re specifying, but if you click that box it will launch a color picker that will let you extract any color from the entire page.  It’s your standard magnifying glass picker, so you can get right down to the pixel level with the color you’re choosing.  Great if you’re trying to match styles from one part of your page to another.

There is also a slider that lets you set the alpha level.

Console API

The last thing I want to share isn’t really a helpful feature as much as it is a “hey that’s pretty cool” feature.  In your JavaScript code, whenever you write out a console.log, you can style the text anyway you want by using the %c format specifier, and then passing it a string of CSS styles.  I guess if you wanted to show a certain error as GIANT RED TEXT then this would be useful, but other than that it’s just a fun way to make debugging less boring.

You can see more info about the Console API and all of the other neat things you can do with Chrome DevTools by checking out the documentation on their website.

Ref: the random CodePen I used in my screenshots

CSS multi-language support

Chiuhua Chen, senior front end developer and prototyping expert at Perficient XD, is currently working on a web application that has a visual design supporting only english language. As with every other project, the business later on proposed support for multi-language support. When the application is in another language, spanish or Chinese, due to design constraints, the page appears messed up with some text occupying more width than what is actually allocated. On further research and checking with other peers, Chiu is working on implementing language specific stylesheet which would override the generic css file to take care of this issue. Lead front end developer Jacob Schulke has a few good points on the topic and has already shared his thoughts here. To learn more on how Chiu is tackling the multi-language css support issue, get in touch with her here.

Apache Virtual Hosts

Derek Montgomery, senior front end developer at Perficient XD, with a strong penchant for infrastructure setup and command line coding, is currently working on setting up a new virtual host for Perficient XD and doing further research on the topic, agrees that “If you have made a website, you have probably used Apache. One widely used application of virtual hosts is shared web hosting, whose prices are lower than a dedicated web server because many customers can be hosted on a single server”. He points out virtual hosts can potentially solve problems such as –

• I have one domain (perficientxd.com), but I want multiple subdomains (e.g. dev., client., etc.).
• I have one IP address available, but I need to test how multiple subdomains would function(use ports)!
• Cost efficient, and pretty easy to configure and test.

To learn more on apache virtual host or if you are using them on your next project, shout out to Derek here. He is always there for everybody.

jQuery Best Practices

Harish Bhavanichikar, lead front end developer at Perficient XD, having worked on javascript, jQuery and other frameworks extensively on a number of projects shares some of the simple, easy to implement, effective best practices for the jQuery framework. He mentions how to do DOM manipulations the right way, handle events without event bubbling, clean ajax calls, check for deprecated methods and some general jQuery guidelines mentioned below –

• Do not use jQuery 2.x if you are supporting IE 6/7/8.
• Keep all your javascript and jQuery at the bottom of the page.
• Do not load multiple jQuery versions.
• If you are using other libraries like prototype, mootools, zepto, etc that uses $ as well, for jQuery functions simply use jQuery and return control of $ back to to the other library using $.noConflict()

The reference sheet can be accessed here.

HTML Web Storage

Jason Ripplinger, senior front end developer at Perficient XD, adept at integrating data with the presentation layer, tells us that HTML web storage is a great way to store the data locally in the browser, offering great advantages such as –

• Uses less bandwidth –  cookies are sent with every HTTP header.
• More secure – because the data is stored locally, the server has no direct access to it.
• More storage room – cookies only allow 4096 bytes per cookie, web storage allows 5MB per domain.
• Super easy to use – no plugins or libraries needed.

He further adds that web storage supports IE8 (did you know that ?) and data is stored as name-value pairs in strings and easily convertible to other formats. One best practice he suggests is to do a check to make sure the browser supports web storage before trying to access it and to use web storage only If there are no concerns about data being deleted. Get in touch with Jason here to learn more about how he has leveraged web storage in his current project.

IA, Visual Design and UI – LeanUX

Michael Gorgone, Senior Front End Developer at Perficient XD, with a keen interest and great knowledge on Information Architecture, opines that, “in most projects, by the time the IA is done and the wireframes are produced along with the visual design, we, the front end developers don’t seem to have much leeway to give feedback as to problems or issues they think could come up. Most cases, FEDs are not allowed to make any suggestions to the layout or where things could be improved without avoiding a confrontation with the visual design folks. Or the client has already approved the design and so changing it could cause a problem – business thinks the design is done but now it isn’t and has to be reworked. LeanUX is something geared towards helping with these issues. I think we need to have the IA, Visual Design and UI folks working together when the wireframes and Ixd is being done so that there is more collaboration and agreement as to what we have resulting in less re-work and more of a final product when it comes time to turn it into a prototype.” If you do not agree, or to discuss more, reach out to Michael here.

In the past few weeks, I’ve seen no less than five different companies publish an article documenting their internal CSS frameworks; it’s a fascinating pattern.  Getting an inside look at how other people (or companies) are organizing code and what tools they are using is a pretty fantastic way to become a better developer yourself.  Take a look quick look.

1. GitHub’s CSS
2. CSS at Lonely Planet
3. CodePen’s CSS
4. CSS at Groupon
5. CSS at Plataformatec

The benefits of having a defined development process are plenty: streamlining your workflow, code reusability, greatly decreasing the amount of time it takes to ramp-up new developers; the list goes on.
What are some of the things you or your company does to organize the structure of your code?