Is my IDE right for me?

Is my IDE right for me?

collection of integrated development environments

What is an IDE anyway?

Before we get into the review, it is important to have a firm understanding of IDE. In short an IDE, or Integrated Development Environment, is an application that provides a work area for computer/web programmers to develop software and web applications. IDEs generally comprise text editors, build automators, and debugging suites. This may not be true of all development environments but it is a start.

Yet another text editor…

As a professional front-end web developer with a few years of web experience (college, internships, full-time employment), you can imagine that I, as well as countless developers, have used a variety of development tools and environments. These environments range from the most primitive, featureless text editors to the lavishly and, perhaps even overwhelmingly, complicated development suites. Each provided the necessary tools to complete the job at hand.

Having seen so many different styles and approaches to development environments, I have questioned why we choose certain editors, barring the editors prescribed based on curriculum (looking at you Dreamweaver), and ultimately what features are the most desirable in my day-to-day editor.  I will be reviewing Github’s brand new editor Atom. Atom is a full featured IDE out of the box, it professes to be the “hackable editor”, and best of all, it is FREE.  This makes Atom a perfect candidate to test drive for a week.  I am in search of what makes Atom special, what makes it different, and better yet, will it be my new coding home?

A handful of co-workers have already made the switch to Atom from Sublime Text 2.  I decided to hop on the Atom train in search of idealistic IDE, but more realistically an IDE that provided the features I have come to desire from my work environments out of the box.  These are the three main criteria I have used in picking a development environment in the past, some of which may apply to you as well.

  • Extensible – how hackable is the core editor?
  • Plug-ins – can extra features and skins be added into the editor?
  • Performance – can this editor hold up to day-to-day development?

Not all of the editors used in the past have stacked up perfectly to these criteria but they certainly serve as a great guideline in choosing an editor. There is peace in knowing what your editors can and can’t do out of the box before getting too attached. While my search for “the right” IDE isn’t limited to these three criteria, I believe they set a solid foundation to help narrow the IDE choices. Again, this is personal preference so your milage may vary. I gave Atom a spin for a solid week, putting it through the paces of deadline driven e-commerce maintenance. Here’s how it fared.

The results are in.

Extensible

The first noticeable feature of Atom is how open and extensible it is. Github built Atom with the intention of giving the user full control, and Atom definitely does not disappoint.  It comes with over 70 core packages out of the box. You have the ability to turn these packages on and off and can even open up the source of the package and edit it right inside Atom. If the core packages don’t meet you requirements, you can add others from the community or create your own packages. Any part of Atom can be touched so you can truly hack Atom to run the way you’d like.

The extensibility doesn’t end at the package level. Atom includes quick customizing resources like “Init script” and “Keymaps” to help even further tune and customize the Atom experience.  I’ve found this to be very helpful in making minor customizations without having to go deep into packages to adjust settings. Atom also comes with a command line interface so that you can quickly get in and out of editing right from your terminal.

Another note, because Atom is a product of Github, it has a large community following which in turn opened the door to a lot of package development and maintenance from the community.  For me this is a huge win and probably the most exciting part about Atom.

Plug-ins

Who doesn’t love plug-ins? Atom seems to agree. I found it incredibly simple to to get the same look and feel out of Atom that I was previously achieving from Sublime Text 2. Many have compared Atom to the likes of Sublime and I, too, must agree. There are definitely noticeable differences, but we will get to that in a second. The list of  plugins and themes is extensive so I didn’t feel like I was missing out on anything when customizing my editor experience.

Performance

One of the more critical factors in choosing an IDE is how it performs. A slow editor makes for a frustrating coding experience, the same can be said for overly bloated IDEs or a featureless IDE.  Atom does an exceptional job at balancing customizability and functionality, but it must be noted that the more you add the slower Atom will perform.

Those switching from Sublime will be accustomed to the palette in Atom. It has the same input drop down at the top of the editor. This palette lets you switch between files quickly and perform task on files without having to click through the menu. Atom has a very clean and intuitive settings panel. It displays how much time each package adds to Atom’s start time – this is a nice feature to have and can help wean out some of those “not so necessary” plugins.

My Thoughts

Ultimately, I enjoyed using Atom and must say it is my daily driving editor of choice now. This is not to say that I think Atom is the best editor of editors, but I can see it’s potential. Much of native Atom felt very similar to Sublime, while also introducing some neat features. I feel that Atom is an attractive editor, but it is not without its flaws.

There is much to be said about some glaring “misses” in Atom. Out of the box, I anticipated much deeper .git integration but was sorely disappointed. I liked seeing the changes to files in the tree view but certainly was hoping for perhaps seamless ‘git diff’ and ‘git log’ features natively. Some features in Atom also felt sluggish in comparison to Sublime and Atom just has an overall different approach to things. Switching between projects was not as enjoyable in Atom as it was in Sublime; I ended up installing a plugin to achieve a better experience.

Although there may be some initial doubts with using Atom, you have to keep in mind that there is most likely a solution from the community. I like where Atom is going and what it is based on.  Atom professes to be a hackable editor, and it shows. Atom is built on modern front end technologies so getting into the core and changing things is familiar and, dare I say, fun. I’m happy with how Atom runs and works and I’m excited to see where it goes. If there are parts of Atom that you don’t enjoy or think can be handled in a different manner, you can make those changes or find the solution from the community. Atom stacks up to some of the more mainstream development environments at a FREE price tag. There are a lot of editor options out there and Atom might not be the answer for every developer;  I wouldn’t choose an editor because it’s “cool” or because it “looks nice”, chose an editor that meets your daily editing needs. Happy editing!

Sources:

https://www.atom.io/docs
http://discuss.atom.io
https://github.com/atom
http://en.wikipedia.org/wiki/Integrated_development_environment

Hover Intent

This article presents the second example in a series from Progressively Enhance It! at Barcamp Philly.

In this example, we’ll use jQuery’s data and Underscore’s delay to detect hover intent on a navigation menu. Detecting hover intent is important so that a dropdown menu does not show if the pointer is simply passing over the navigation, when it is not the user’s intention to show the dropdown.

Our example navigation menu looks like this:

hover-intent-image

And the relevant HTML for our example looks like this:

<ul class="nav" role="navigation">
    <li>
        <a href="/categories/men">Men</a>
        <ul>
            <li><a href="/categories/men/soft-shell">Soft Shell</a></li>
            <li><a href="/categories/men/fleece">Fleece</a></li>
            <!-- … -->
        </ul>
    </li>
    <!-- … -->
</ul>

Let’s assume we have showDropdown and hideDropdown functions to show and hide a dropdown menu. Those functions can toggle a class value, call a jQuery method to hide/show, or otherwise implement the actual hiding and showing.

Our initial implementation (without hover intent), looks like this:

var showDropdown = function () { /* … */ },
    hideDropdown = function () { /* … */ };

$('.nav')
.on('mouseenter', '> li', function () {
    showDropdown();
})
.on('mouseleave', '> li', function () {
    hideDropdown();
});

This code will show menus immediately on mouseenter, which may cause menus to open when a user is simply moving the pointer over the navigation to reach another part of the UI.

To solve this problem, we’ll set a flag (a boolean) on each top level menu item when a user mouses into it. We’ll also set a short timer. When the timer expires, we’ll check the flag to see if the user is still hovering the same item. If so, we’ll assume the user intends to hover and show the corresponding dropdown menu. We’ll reset the flag whenever the pointer leaves the element.

To set the flag, we’ll use jQuery’s data method. This method lets us store arbitrary data (in this case a boolean value) on a particular DOM element. When called with a single string argument, the data method will retrieve data with that name that is stored on the element. When called with a second argument, the data passed as the second argument is stored on the element. The first argument is the name given to that data (used to retrieve the data later).

We also need to set a timer, and to do that we’ll use Underscore’s delay method. The first argument to delay is the function to execute after the delay expires, and the second argument is the length of the delay in milliseconds.

Our final implementation looks like this:

var showDropdown = function () { /* … */ },
    hideDropdown = function () { /* … */ };

$('.nav')
.on('mouseenter', '> li', function () {
    var $this = $(this);

    $this.data('isHovering', true);

    _.delay(function () {
        if ($this.data('isHovering')) { showDropdown(); }
    }, 500);
})
.on('mouseleave', '> li', function () {
    $(this).data('isHovering', false);

    hideDropdown();
});

This is indeed a naive implementation of hover intent but illustrates how to use some useful library methods. For a more robust hover intent, consider using the jQuery hoverIntent plugin or look at an entirely different approach used by Amazon and explained by Ben Kamens.

Summary of features

The library features covered by this example are:

jQuery’s data
Underscore’s delay

WebLinc.com Performance Updates: Part 1

I have recently taken ownership of the development of WebLinc.com. I’ve been a WordPress developer for the past 5 years and try to give back to the WordPress community when I can. Around the time when I was taking over the development for the site, I saw this tweet from local designer Jody Ferry:

Needless to say… “Thems fighting words…”

The Easy Win

So I got to work reviewing the site to how it could be improved. First I went to WebpageTest.org and ran some tests to create a baseline.

baseline

Based on the results from the WebpageTest, I saw that there were images on the homepage that could be optimized. Images are typically the number one culprit when it comes to long load times (which Jody’s tests were measuring). Saving out the images through Photoshop’s “Save for Web” feature with ~60% quality and as a Progressive JPG greatly reduced the overall size of the page. Before I pat myself on the back, however, I knew there was still a lot of work do.

Overall page load time is a very poor indicator of page speed and performance. The key metric we want to focus on is how quickly our user’s can interact with the site. What good is a really lightweight webpage if the Time to First Byte is 3+ seconds long? Thankfully, WebpageTest has a metric, called “Speed Index”, that provides a good indication of how quickly the user can interact with the site.

For the People

New goal: make it fast for the people using our site. Notice how I didn’t say users? I think sometimes we forget that users are actually people, and that no one likes a slow website. Updating the previous step was easy because we were really just optimizing the assets we were including into our application. The next step is where the real work comes in. Now we need to rework the application to be more efficient. This involves caching and understanding how the browser renders web pages. Stay tuned for part two.

Developing for Accessibility

The importance of accessibility.

Web accessibiity topics

Accessibility on the web means designing and building websites so that everyone can use them. The UN recognizes access to information and the web as a basic human right. As creators of the web we are morally, and legally, obligated to provide an equal opportunity for people to interact with our sites. The W3C Web Accessibility Initiative (WAI) provides the necessary guidelines and resources to deliver on this responsibility.

There are more than 6.6 million people in America alone that are registered as visually disabled. This is just the surface. Think of your parents, or grandparents, whose vision is fading with age. They increase font sizes, zoom excessively and struggle with complicated interactions. They are probably not part of the statistic but they will benefit from an accessible web. Accessibility isn’t just about delivering sites for the blind or visually impaired. It means removing barriers that prevent access to websites by people with disabilities.

Accessibility tools at our disposal

For large, or legacy, sites providing a truly accessible experience can be a daunting task. Thankfully, WAI and the W3C provide us with a full toolkit to deliver accessible websites that meet section 508 and WCAG standards.

ARIA is the most comprehensive set of tools that we can use to enhance the experience of our sites. Adding ARIA attributes to markup allows us to specify live content areas, alerts, and other important interactions without making massive changes to the existing structure of the site.

Some of the most important ARIA roles are the Landmark roles.  They make it easier for screen readers to navigate a page.  While navigating through elements on a page using JAWS is relatively easy, without using landmark roles it becomes difficult to understand the context of those elements.  JAWS uses the ‘;’ key to navigate landmark roles.  As you navigate the page, JAWS announces which landmark you are on.  There can only be one landmark per page (think the ‘id’ attribute), because there is no need to give the roles to multiple regions of your page.  A user using a screen reader should not have to navigate through multiple elements on a page with the same exact functionality.

To see ARIA roles in action, Zoe Gillenwater has a nice list of videos that demonstrate how they interact with screen readers.

A neat little tool you can use to see established ARIA landmarks on your page is the Juicy Studio Accessibility Toolbar available for firefox.  It can outline a page’s document landmarks and show you a list of roles and properties a page is using.  It also comes with a simple color contrast analyzer that grades your page’s text and background color contrast.

Accessibility Audits

In order to improve accessibility we must first understand our current status. There are a few powerful tools that can give you a baseline for accessibility and highlight any areas of concern.

Accessibility audit for Chrome Dev tools is a powerful browser extension that adds accessibility audits to Chrome’s Dev tools. Once installed you can find the extension in the ‘audits’ tab of dev tools. Running the audit will check your page against Section 508 and the WCAG 2.0 specification as well as various ARIA rules. The report will highlight errors and display warnings along with a link to a description of the test, which shows examples of the error and how it should be resolved. Further details can be found in the Chrome dev tools accessibility wiki.

The wave app from webAIM is another accessibility tool that works well. It provides a visual representation of accessibility issues and may be more intuitive for non-developers to see issues. I would suggest using wave to get a deeper look at accessibility issues on specific pages.

While these tools certainly provide value and are a quick way to get an overview of your site from an accessibility standpoint, they overlook the experience of interacting with your site. In my opinion the most valuable tool to test accessibility is a screen reader. After all, empathy is the key to great design. The most widely used screen reader on the market is JAWS for windows, there are free trials available so go download it if you can – alternatively osX has built in screen reader functionality and there are a number of browser extensions available. Running through some sample use cases, or user journeys using this technology should highlight accessibility pain-points in your existing site.

Closing thoughts

Even though we know accessibility to be important, it can be a difficult thing to sell to a client. There are various inherent benefits to accessibility, including improving SEO, being device agnostic, and providing a better user experience – especially for older audiences. Despite these benefits we shouldn’t be selling accessibility to our clients. It should be provided as standard, out of the box: It is our responsibility – not our product.

Transmedia Storytelling & eCommerce

transmedia

Telling a great story is essential to any eCommerce experience. With web content now being accessible in numerous ways on various media types, creating a story that transcends its device and platform helps to create a better overall user experience.

Henry Jenkins, an American media scholar and professor, proposed the idea of transmedia storytelling in 2006. In short, transmedia storytelling is: telling a single story (or story experience) across multiple platforms and formats, using current digital technologies.

Designers and developers can use the Transmedia Storytelling theory to help shape their design and development decisions.

User Participation

An added bonus of transmedia storytelling is that often times, users play a major role in contributing to the story that is being told. This can be seen on the web through things like product reviews, blog comments and social media shares. This type of user feedback, whether positive or negative, will become a part of the overall story being told.

What This Means for eCommerce

Developing a good story may be one of the most crucial parts of creating an eCommerce experience that users will enjoy and want to engage in again. Designers and developers become story writers for the web. Many of the design decisions are influenced by the need to tell a client’s ‘brand story’ across as many platforms as possible. The correct decisions should result in a successful checkout conversion, which is the ultimate goal of any eCommerce site.

An Everyday Example of Transmedia Storytelling

Meet Ally. She’s a hardworking young adult who enjoys hanging out with friends and trips to the beach. She heard about the brand Free People from her friend who was wearing an amazing new summer dress. She visited their website for the first time, added a few items to her cart, but didn’t complete the purchase. Later, while on Facebook, she sees a Free People ad, likes their Facebook page, and decides to venture to their site again. After some more browsing, Ally finally makes her purchase.

Ally is excited about her new outfit and sends a picture to several of her friends.. From there, her friends visit the Free People website, and some even download the mobile app. The story then continues as new users visits the site, share it with their friends, and become Free People customers.

All of these media platforms: the website, Facebook, the mobile app, and even the text messages that Ally sent, help to shape Free People’s story. Their web designers started writing a good story of their own, by making the right decisions, and their customers were then able to build upon that by supporting and sharing the brand across several media platforms.

Everyone loves a good story. Today one of the most popular places to tell a story is on the web. Many of these stories tell of a specific brand and the experience that it creates. People experience the web in a variety of ways which means they can engage a story in many ways. Although this may seem like an obvious statement, it is a concept that was not as obviously understood until the development of Jenkins’ theory of new media known as Transmedia Storytelling. Kudos to you Mr. Jenkins!

Source:

http://henryjenkins.org/2007/03/transmedia_storytelling_101.html

A Front-end Exploration of Firefox Developer Tools

Firefox 35 showcases sleek new features and a friendlier dev tools experience, while some features still fall short of the competition.

Internally, our front-end development team is full of Chrome users. In fact, 100% of those surveyed agree that they use Chrome ‘most of the time’ for inspecting, console logging, and in-browser CSS and DOM manipulation. So when Firefox 35 touted new dev tools features, we had to give it a test run. For 2 days, we swapped our Chrome browsers for Firefox, and used their developer tools for our daily front-end tasks.

New Features & Improvements

Older Firefox developer tools were often regarded as slower and clunkier than Chrome. Optional Firebug felt faster and better and often times more up-to-date than Firefox, but the add-on could leave developers with two sets of tools open at once. The new Firefox Dev Tools is fast and responsive, and contains new features that eliminate the need for a 3rd party plugin.

  • Responsive Design Mode – The new ‘Responsive Design Mode’ button allows for testing and emulating different devices. Compared to Chrome’s ‘Toggle Device mode’, it measures up and even excels in areas of intuitiveness and usability.
  • CSS Panel Improvements – Editing CSS styles is also less of a hassle than in previous versions. Firefox 35 and up now allows for inspecting pseudo-elements, a feature Chrome users will find familiar. Space for new styles is reserved at the top of the column and numeric values can be dialed up and down as expected.
  • Event Listeners Icons – Firefox 33 introduced another new feature to their inspector panel: event listener icons. Seeing which DOM elements have event listeners is easy at a glance. The useful popup provides filenames and line numbers, as well as a pause button to insert breakpoints for debugging.

Existing Features of Note

Some of the features we liked were not actually new; we’d just never become fully acquainted. Since the performance and usability have increased across the board, it is now much easier for these older features to shine. Here is a short run-down of existing features of note:

  • Style Editor – Sometimes developers need more flexibility than the CSS Panel offers, and the ‘Style editor’ tab allows for fast editing of media queries and re-scoping styles in context. This is possible in Chrome via the ‘Resources’ tab, which is tucked away compared to the ease of Firefox’s editor.
  • View Cookies – Viewing set cookies is easy in the network tab, and requires no 3rd party plugin. An add-on is still required for editing, but having something fast and built-in is a plus.
  • Paste Outer HTML – This feature, introduced in Firefox 32, allows for quick pasting and replacing of an element’s outerHTML markup.
  • Split Console – Optional persistent console means that developers never have to close the console while performing other actions in the tools panels.

Drawbacks

Although Firefox 35 has a lot to offer, there are still some drawbacks that may need to be addressed in future releases.

  • Dragging DOM nodes in HTML Pane – As of Firefox 35, there is still no way to drag DOM nodes around in the Inspector html pane. The ‘Edit as html’ option in the context menu does serve as a potential workaround for this, but this view can be cumbersome when editing large blocks. However, the Paste Outer HTML option (see above) provides a small concession.
  • Inconsistent Inspecting – For those who prefer the right-click context menu as a shortcut to inspecting an element, Firefox developer tools displays several inconsistencies in performance. Selecting ‘Inspect element’ from the context menu will often default to selecting the body tag – or worse – bring up a blank ‘Inspector’ html pane until the page is refreshed. The ‘select element’ icon works as expected, but daily workflows might be inhibited for those who find the right-click context menu more intuitive.

Conclusion

After the 2 day run, it is working well as my new default browser. The newer version definitely outperforms its predecessors and offers solid developer tools for web professionals, which is great news for open source aficionados. Many of the features are better than the competition, and it appears that Mozilla is focused on providing a solid developer toolbox. Though Chrome is a bit better at dealing with the above-mentioned concerns, it would be easy to switch from time to time and incorporate Firefox into a productive development workflow.

Firefox versions:

Latest standard release: FF 34.0.5 (since article was written – previously 33)
Developer edition used: FF 35.0 a2 (a = aurora update channel) (now it is at 36.0)

Sources:

https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector
https://developer.mozilla.org/en-US/Firefox/Releases/35

Components of Responsive Web Design: Universal Design

Responsive web design means creating a website that can be utilized effectively, used with ease, and accessed from any device. A web designer or developer must consider a number of factors to create a truly responsive website. He or she must follow the Principles of Universal Design, keep the outliers of their user base in mind, and communicate the importance of these principles to his or her clients clearly without making responsive web design (RWD) sound like an arbitrary buzz-phrase. To an end user, RWD means having a transparent experience with an end product devoid of design hindrances.

Why Universal Design?

“Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.” 

Ron Mace, Founder of the Center for Universal Design

universal-design ven diagram with responsive subset
Principles of Universal Design1 are a set of guidelines and recommendations used to create products without the need for bespoke design. RWD is a subset of those principles. If we think of it as a Venn diagram, RWD fits neatly into the greater Principles of Universal Design parent. Using these principles, a web developer can tailor them to his or her user base. The user experience is at the forefront of this endeavor, and therefore, it is important for developers and user experience (UX) researchers to work in tandem while developing web products.

Who is the user?

A user, for our purposes, is a person who utilizes or attempts to utilize a web product. Usability is the ease with which the users interact with and are able to learn to use the product. Usability in a user base tends to follow a normal distribution2 and, therefore, a normal bell curve. The distribution of users within this bell curve is dynamic; therefore an average user may become an outlier depending on the task.

By designing for the 1% of outliers on each side of the bell curve, web developers and designers can ensure that they include that percentage of users who aren’t average, providing a positive and usable experience for as many people as possible within their user base.

Design That’s Not Just for Different Screen Sizes

RWD is more than just designing for different screen sizes; it is also designing events that adapt for different devices. It means ensuring that a click event translates well to a touch event and that information on a page is accessible by a screen reader. The design and implementation must be flexible enough to work in any unpredictable environment. To an end user, RWD should create a consistent interactive experience. For example this means:

  • Clicking on “Next” in a photo album translates to a swipe on a smartphone or tablet
  • Making contents of a navigation menu that open on hover readable by a screen reader
  • Checking statistics on a tablet about the open rates of an email is as simple as on a desktop

How to Respond to Naysayers

Responsive web design has become a buzz-phrase to which some react negatively. Some might even refer to it as “internal marketing jargon”.3 Therefore, as designers and developers champion for RWD, they must use clear descriptions and examples when communicating. RWD is not a set of practices or definitive style sheets set in stone. Rather, RWD is an evolving practice based on the responsive design theory.

Responsive web design doesn’t stop at how a website looks, is displayed, or functions. It also encompasses the overall Principles of Universal Design. RWD accounts for the unknown, and it allows you to create one site that works for everyone.

1 “The Principles of Universal Design”, ncsu.edu. NC State University, The Center for Universal Design. Web. 16 May 2014, http://www.ncsu.edu/ncsu/design/cud/about_ud/udprinciplestext.htm
2 Neilsen, Jakob. “Outliers and Luck in User Performance”, nngroup.com. Neilsen Normal Group. Web. 15 May 2014, http://www.nngroup.com/articles/outliers-and-luck-in-user-performance/
3 A survey preceding this blog post found that some who are not familiar with RWD theory consider it simply “internal marketing jargon”

Testing your front-end for i18n with the pseudo-localization widget

When websites reach a critical mass in popularity, the need for localization becomes apparent, as it is the best way to reach a larger audience. To accomplish this, site owners often commission third parties to assist in the site translation. The question few seem to consider is “Will my site look as clean and polished, or even similar once translated?”  The answer is almost universally ‘no’, with few exceptions.  We have developed an application for pseudo-localizing that will test all of the common problems encountered with localization, letter accents, word length, directional display, and text node anomalies.  Instructions for downloading the extension are included at the end of this post.

There may not be many issues translating the site into a similar language that derives from a source language close to the original. But as the goal is to drive diverse traffic, this is often not the case.

Some phrases, when translated, are much longer or shorter than the source language. This alone wreaks havoc on a site’s carefully designed UI. Elements often extend further than they should, or worse, the text overflows and is either hidden or layering over other text.

Another unexpected change occurs when the new language is read in a different direction than the original. Arabic script and Hebrew are both read from right to left, which can directly impact the user’s interpretation of the site’s structure and confuse them in their navigation attempts. Finally, characters and font glyphs may be unavailable to some users; it is important to avoid a translation containing an errant glyph that disrupts the user’s interpretation.

So how do we deal with these problems? Developers need a tool that will allow them to preview the state of a site once all of these issues have been applied in order to write in a fix for them. Enter pseudoL10N.

Pseudo-localizing

Our app is a one-stop shop for pseudo-localizing needs, as it can test all of these common problems individually or at once. An explanation of how each option functions and why it is important follows.

pseudoBase

Base page with no alterations

Accenter

The accenter iterates each character in a text node, matching it with its accented counterpart using a predefined unicode dictionary. The value is then converted from unicode to readable text and output.

The accented value helps developers see which characters may display improperly due to font-size and available glyphs for the specific font used.

pseudoAccenter

Length Modifier

The length modifier takes each text node that is passed into it and calculates its length. It then uses this value to multiply against the specified difference. If the length is greater, it adds in the proper amount ‘equal’ characters on either side of the text node and outputs it. Conversely, if the length is smaller, the output is reduced from either side of the text node.

The length modifier simulates the appearance of a site when phrases are translated into languages with different average lengths. Percentages are used as there are often pre-existing data on comparable phrase lengths for different languages that a developer can use to test.

pseudoLenmod

Fake Bidirectional

The page is simply told to display text from right to left rather than left to right. It is an attribute added to the body element.

Fake Bidirectional is simple in that it only affects default alignment for most elements. Useful in that it often reveals the flaws in floated elements when they start to crash into text nodes.

pseudoFakeBidi

Brackets

This option inserts a pair of brackets into each text node: an opening bracket at the beginning and a closing one at the end.

The brackets encapsulate each text node so that any unintended truncations of nodes or any other anomalies are immediately apparent.

pseudoBrackets

pseudoAll

All pseudo-localizations at once

Localization

Finally, the localization of a site itself is also essential. While being able to preview the appearance of a site in a variety of technical aspects is invaluable, the ability to see the actual language on the page is important as well. The widget allows the user to quickly run their page through Google Translate and get machine translated text back. Additionally, it would be wise to apply the pseudo-localization to this translated page so that the end representation is as accurate as possible.

Final Thoughts

In order to use the extension, you can pull it down from the github link provided below and install it as a ‘developer extension’. The instructions to do this are also below.

If you find any bugs or simply want to add to/contribute to the project, feel free to either submit a report or fork the project and work on it yourself. Just submit a pull request once you’re finished.

Be like a newb

Picture of cartoon character proposing a question.

It’s quite embarrassing when the bright spotlight of our peers’ attention shines on our gaps of knowledge. Many people quickly formulate a white lie to avoid this embarrassment. We work in a competitive and advancing industry: we need to prove our technical worth in hopes of maintaining our relevance as craftsmen. We don’t want to admit when we don’t know something. Nodding our heads when we don’t understand is a big mistake. Covering up lack of knowledge only keeps us from the answers; instead, we need to fill in those gaps of insight.

Being like a newb makes you a better expert

We were once novices full of questions and hungry for answers. Our modest view of our own skills forced us to listen and learn, which allowed us to grow. As we become experts we often mistakenly abandon these behaviors. Acting like a novice means re-acquiring humility, that is, understanding that our own skills may not be equal to those of our peers. Humility enables consistent improvement — let’s examine how.

Humility promotes improvement

Humility means admitting a lack of knowledge and asking questions. Remaining humble and getting answers to those questions makes you smarter. Believing you’re the expert in the room only makes you the least able to learn, and promoting that idea makes you less approachable. In our ever-advancing industry there is always a better solution around the corner. But if we’re convinced we already have the best solution, how can we see the possibilities for improvement?

It makes for a better team

Understanding how little we know makes us less likely to judge our peers for their mistakes. A lack of humility could cause us to permanently damage the team’s ability to collaborate. In our quest to prove our technical prowess we might be tempted to draw attention to the mistakes of others in a disruptive way, which encourages them to cover up future mistakes. This breakdown in communication could lead to significant problems and misunderstandings.

Enjoy being wrong as much as you enjoy being right

“There is no such thing as a failed experiment, only those with unexpected outcomes.” – Richard Buckminster Fuller, US engineer

Novices understand that there’s nothing wrong with being wrong. When others are willing to constructively show us our mistakes, they give us a golden opportunity to improve. Criticism provides a shiny surface for reflection, which in turn helps us improve ourselves. Criticism can be difficult to accept, especially if it is not delivered in a tactful way. Try to keep your personal feelings out of the situation and focus on the message. View it as a chance to learn rather than a failure.

It takes a village

A single person has limited knowledge; therefore teams are needed to produce complex software. Approaching situations from a novice perspective and re-developing humility enables collaboration, and collaboration is the oil that keeps a team running smoothly.

Web Performance Checklist

Website performance and page speed are important not only to your users, but also to your bottom line. According to Mobile Marketer and as cited by Luke Wroblewski in his article on ecommerce and page speed:

“When you are doing business on the Web, every second counts.”

Gomez. (2010). Why Web Performance Matters: Is Your Site Driving Customers Away? [White Paper]. Retrieved from http://www.mcrinc.com/Documents/Newsletters/201110_why_web_performance_matters.pdf

The Compuware-owned firm’s study demonstrated that 58 percent of people expect a mobile Web site to perform like a desktop Web site. If a page load takes more than two seconds, 40 percent are likely to abandon that site. And, finally, “the average impact of a one-second delay meant a 7 percent reduction in conversions. For the $100,000 per day ecommerce site, a one-second delay means $2.5 million in lost revenues in a year.”

With such a high impact on User Experience (UX) and ultimately conversions, the WebLinc team takes page performance seriously. We recommend various techniques to ensure a site achieves peak performance.

Performance Techniques

Getting a Baseline

Performance testing requires a baseline measurement. WebpageTest.org is an excellent tool. This industry standard site takes a snapshot of a page’s current load time, render time, and asset breakdown and offers some basic performance suggestions. WebpageTest.org can compare current measurement data with previous tests to evaluate the difference when a new feature or performance enhancement is added to a site.

Images

Images are generally the largest contributor to the total download size of any web page. It is important to serve users the smallest possible file size without affecting image quality. Use the “Save for Web” feature when exporting images from PhotoShop. This feature removes any meta information that inflates the overall size of the image. Be sure to use the “Two Up” view setting, and move the quality slider to lowest setting possible before invoking artifacts in your optimized image. Pay special attention to text and areas that use the color red, because this is where artifacts typically present themselves.

In addition to optimizing the quality of the image, check the “Progressive JPEG” option, which is recommended in the WebPagetest.org baseline. It might be helpful to save your Progressive JPEGs settings as a preset for future use.

CSS

Cascading Style Sheets (CSS), is the website code that gives life to designs. The overall look changes how paragraphs, headings, layouts, etc. appear on your site. Create a style guide for your site to ensure your CSS is as lean and efficient as possible. A style guide hones the “visual language” of a site to ensure consistency. A streamlined hierarchy of headings, text, and graphic elements reduces the number of redundant and/or page specific styles.

JavaScript

JavaScript (JS) adds the special functionality to a site. Like CSS, JS is a render-blocking asset and should be loaded at the bottom of the site’s HTML code, just above the closing >/body<. Some JS, like Modernizr, must run in the >head< of the document, and should remain as short as possible. Just like CSS, it’s important to remove any unused or excessive JS, as it adds to the download size of the page.

Reduce HTTP Requests

The browser makes an HTTP request to a server, such as a hosting site or a third party server like Facebook or Twitter. Each request takes time to execute; reducing the number of requests reduces the download time of the site.

Asset Concatenation

One way to reduce HTTP requests is to concatenate files that are used on your site. A site may require several CSS or JS files to create advanced functionality like a lightbox or an image carousel. Instead of calling these files separately, they should be added together with your main CSS and JS to create one large CSS or JS file. Reducing the number of files reduces the number of HTTP requests.

Image Sprites

Another great way to reduce HTTP requests is to combine images into a single file called an image sprite. Image sprites are essentially large filmstrips that connect many different smaller images. CSS is then used to crop the larger file so you present the end user with a single “frame” of the great image sprite.

Minify Assets

Surprisingly, white space in documents increases the download size. Remove spaces and carriage returns for faster downloads of text based assets. Specially designed software like YUI Compressor employs a set of rules to remove all white space from your CSS and JS while maintaining the same functionality. Typically you can keep two sets of files for each asset, a minified and an expanded version. Developers will be able to read the expanded version, while computers can read the minified version.

Optimize Render Block Assets

As previously mentioned, CSS and JS are render blocking assets and their placement on the page can significantly affect the speed in which users can interact with the site. Making sure JS is always after CSS and as far down in the code as possible is just the first step. Many times JS can be loaded asynchronously. This means that the server can load the JS without interfering with the display or rendering of other assets on the page. Loading JS asynchronously turns JS into a non render blocking asset, allowing your users to interact with the page more quickly.

Implement a CDN

A Content Delivery Network (CDN) is a way to bring the physical location of assets closer to the users who are requesting them. As we discussed in the “Reduce HTTP Requests” section, each request is a call to a specific server. A user may be hundreds or even thousands of miles away from the server, so the request can take longer to reach them. A CDN gathers the assets needed for your site, and distributes them in many locations. When a user requests those assets, the time for the request to reach the user is greatly reduced.

Performance Checklist

  1. Get a baseline from Webpagetest.org
  2. Serve Compressed Images
  3. Serve Progressive JPEGs when possible
  4. Optimize CSS to reduce redundant rules and selectors
  5. Optimize JS to remove unused JS and JS plugins
  6. Combine CSS and JS files to reduce HTTP requests
  7. Combine images into image sprites to reduce HTTP requests
  8. Minify CSS and JS files to reduce download size
  9. Load JS after CSS
  10. Load JS asynchronously when possible
  11. Utilize a CDN to serve assets

In Conclusion

Webpage performance is an ongoing challenge. As your site grows, you may need to implement new techniques to maintain top performance. At WebLinc, we constantly perform diagnostics on our clients’ sites to ensure the best user experience possible.