    
|
|
|
I had created some neat icons for a website redesign I was doing, and I previewed the new site on an old iPad. The layout looked OK at normal size, but zooming in to part of the page, I suddenly saw that my icon was a blurry mess, while the text-based header was still crisp and sharp. On a newer Retina-display iPad, the icons didn’t look quite sharp, even at normal size.
The first idea I had was to create double-sized sprite images, setting them to display at half their size using CSS. While this made them look better on a Retina display at normal size, as soon as you started to pinch and zoom, the blurriness returned. But the text was still as crisp and pin-sharp.
The answer was obvious. I needed to turn my icons into a font.
In this tutorial, we’ll look at how to turn vector icons into a web font using a great free web app called IcoMoon. Then, we’ll look at how to use the generated font files and CSS in a web page.
An icon font has several advantages over bitmap images, in addition to image sharpness.
So, let’s get started!
Symbol fonts can be built using a dedicated font-creation app such as Glyphs, but a professional typography tool is way beyond the needs or requirements of building a simple icon font, in which the relationship between characters (i.e. kerning and ligatures) is not important.
By far the easiest way is to use a great free online app called IcoMoon, by Keyamoon, which takes away all of the hassle of converting symbols into a web font.
This HTML5 app takes away all of the pain of creating font files for simple uses such as building icon fonts. IcoMoon comes with a number of icon sets already loaded, and you can add more to your library, most of which can be used for free (check the licensing). If you are looking for fairly standard icons, such as “file download” and “shopping cart,” then you may find that using one of these is preferable to creating your own.
To begin with, you need to create the icons in a vector-drawing program that is capable of exporting to SVG format, such as Illustrator or Inkscape.
While you are designing, you can work with whatever colors you like, but the icons must be one solid color. Make sure each icon is approximately the same size. Having one icon much taller or longer than another will make it hard to build a consistent font. Here, I’ve had to reduce the width of my airship icon so that it matches the others.
Check each icon carefully to make sure it doesn’t have imperfections — details that look OK at smaller sizes may hide little defects when zoomed in. In the icon shown below, I need to remove the jagged steps that have crept in when layering elements.
In Illustrator, use the Pathfinder tool to unite overlapping elements, and the Minus Front element to remove cutout elements, such as the star in these icons.
The key principle is to ensure that your icon is readable at small scales. Simplify as much as possible.
Now, select an icon, and copy and paste it into a new square document (for example, 200 × 200 pixels). Scale the icon so that it fits. You may find it useful to set a baseline ruler. Color the icon so that it is solid black on a white background.
Now, choose <code>File… Save as</code> and save the file as an SVG file. Use the default SVG settings. Once you’ve done this for all of the icons, you’re ready to create a web font.
Open the IcoMoon web app. To import an icon, click the “Import icons” button, and then select the SVG files you want to add — you can add multiple files at once. These will then appear under “Your Custom Icons.” If they are highlighted in yellow, they will be part of the icon font you will create. In this example, you can see I have decided not to export one of my own icons, and I’ve added one of the icons from the “Mini-icons.”
You can click the “Edit” button if you wish to adjust the icon’s position, sizing or rotation. Use the “Save Copy” button to create icon variations (for example, a mirror image of an icon). Add a meaningful tag to the icon, because this will be used to generate the class name for it.
When you are ready, click the “Font” button at the bottom of the screen to begin generating the font. This is where you can assign which icon is mapped to which character; for example, if your icon set is six images of a spinning ball, you could assign the characters q, w, e, r, t and y to the six frames. In the preferences, choose a font name. You can also adjust the font’s metrics, but unless you are going to set your custom font alongside standard text, you don’t really need to worry about this.
Click “Download” to download the font pack to your machine. It will be a subfolder containing the fonts themselves (in WOFF, EOT and TTF formats), as well as a sample HTML page and the corresponding CSS. There’s even a JavaScript file with a workaround if you need to support IE 6 or 7.
To add the fonts to your project, copy the fonts subfolder to your site. You can copy and paste the CSS from style.css into your own site’s CSS file, but my approach is to rename it as fonts.css and keep it as a separate CSS file. You then need to add a reference to this CSS file in your HTML file using the relative link:
<link rel="stylesheet" href="fonts.css" />
In the @font-face element of the CSS file, you will need to change the URL reference to the new relative location of the fonts, or you could simply drop the fonts folder in your style sheet folder.
As you can see in the sample index.html file, there are two ways to reference the custom font, either by its character (unicode or name) or by its class name. The first example uses the HTML5 data-icon condition
<div aria-hidden="true" data-icon="g"></div>
Here, the fs1 class is used to set the size of the font. The aria-hidden reference helps to ensure that the character is not spoken by any screen readers.
The second method uses a span element:
<span aria-hidden="true"></span>
This method is useful when you want the symbol to sit inline with normal text.
If you want to make the icon a link, you can wrap it all in an href:
<a href="http://www.yoursite.com" target="blank" data-icon="s"></a>
Here, I’ve added the iconlink class and given it a hover state:
a.iconlink {
font-family: 'youriconfont';
text-decoration:none;
color: #666666;
}
a.iconlink:hover {
text-decoration:none;
color: #999999;
}
As we’ve just discovered with the hover state, changing the color of the icon is as easy as setting the color property in our CSS, and changing the size is as easy as setting the font-size property. You can also set other properties, such as text shadow and transparency, all while retaining the resolution-independence of a font.
Try it, and I guarantee you’ll never use bitmap icons again.
Have you tried using fonts for icons? How have you found it? Let us know in the comments.
| The WordPress Admin Customizer – only $16! |
 |
 |
In many ways, responsive Web design (RWD) deserves a big share of the honor for making the Web more usable on non-desktop devices. This trend of letting the browser determine more about how a Web page should be displayed makes sense, especially now that mobile browsers are slightly more trustworthy than in the old days of mobile.
However, a responsive website is not automatically a mobile-friendly website. Amid the buzz of trendy Web development techniques, the good ol’ Web server doesn’t get the spotlight it deserves. Modern Web development should be about finding the right balance between server-side and client-side implementation.
Find the right mix of client-side and server-side logic for adaptive Web design.
There is no one right answer to what should be done on the server and what should be done on the client side. That depends on the website in question. It is clear, however, that an either/or approach would fail to meet expectations. I will use a real-life project that my company is working on, with real requirements and pain points, as a reference. We are taking a pragmatic approach to the Web, starting with a blank sheet of paper to find the best solutions for both the technical and business requirements.
Our client in this project is a large global news provider. Mobile is obviously crucial to it, because a large proportion of its audience doesn’t have access to a desktop device. Nevertheless, desktop access is just as important, and the solution needs to account for both.
Like many “forward-leaning” Web projects today, a general requirement was to consider mobile first, from both a technical and business perspective. That means HTML5 and RWD (in its broadest sense), for starters. At the same time, because the client was a global content distributor, having tools that could handle less-capable browsers and devices (ones that don’t support the principles of RWD and HTML5) well was essential.
The real challenge in this project was to make the most of RWD techniques, but also to address some of the challenges of RWD from a mobile perspective. This is where the server-side part comes into the picture. Doing as much optimization on the server side as possible makes sense, to relieve the client of data transferring and the execution of logic in the browser.
The main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, and every millisecond counts, regardless of the business model. Especially for big websites like our client’s, the cost of poor performance adds up to significant numbers. Even if you have many great polyfills that provide shims, with fallbacks for missing functionality in browsers, favoring speed, performance and maintainability over polyfills makes sense.
Another point in favor of server-side device detection is its support of different business models and other business requirements. Advertising and other third-party content is one example that is much discussed, but other requirements need to be met, such as customized experiences for specific devices, like the iPad.
With these considerations in mind, here are some of the requirements identified in our reference project:
A summary of our requirements, which I believe are pretty standard for most current mobile-oriented Web projects. (Image: WPZOOM)
The logical way to approach this is to find a way to combine the best of RWD and client-side techniques with server-side functionality based on device detection. This is sometimes called RESS (responsive Web design with server-side components). The purpose of RESS is to do the heavy lifting on the server, making work easier for the browser, but also providing enough flexibility to meet any business requirements as described above. However, both RWD and RESS are parts of a bigger picture, sometimes referred to as adaptive design.
Making the design adaptive, throughout the value chain, is our goal. Presenting content in a browser is only a part of the story. A lot of stuff happens to the content before it reaches the browser.
From a developer’s perspective, there are no real best practices or dedicated tools for these kinds of requirements. The wheel has to be invented — or at least developers have to be helped to decide which wheel to use when, and how to mount it to different vehicles.
We decided to address the lack of tools. Even if there are some emerging best practices for RWD and good ol’ device-detection software, there are no good tools for combining the two to address the current needs when developing for the ubiquitous Web.
During our project, we identified five areas where the server’s side could be put to work to enhance client-side techniques.
But first, the obvious. The most important server-side component is the content management system (CMS).
If you look back a couple of years, mobile Web development was done by mobile specialists who performed their magic. This is not the case anymore. Web design and development is now driven by Web developers, usually working within, or at least connected to, the client’s organization. This is important to note, because this rules out the traditional approach to mobile Web design, whereby a magic mobile-platform proxy black box produces the mobile website. These platforms are usually based on some sort of proprietary XML format, screen scraping or other custom stuff that has to be learned.
We’re going mobile, but we are not replacing our CMS.
Another reason why a mobile publishing platform is not an option is that it would interfere with the editorial process. Being in control of the content and its behavior is important. So, the CMS is key. Managing all online entities, mobile, desktop, TV and so on from the current CMS makes sense, but going mobile must not require the content owner to change their CMS.
A side effect of making mobile an integral part of content publishing, which was important for this project, is that the Web developers, those working with the presentation of content, are able to effortlessly account for mobile. Mobile becomes a natural part of their work.
The best way to utilize the presentation layer in the CMS and to power-charge it is to tackle a range of devices, operating systems, browsers and interaction models. This is what’s so great about RWD. You can apply the technique on top of any CMS. RWD should be the default baseline of all Web projects. RWD restores fluidity to the Web. For websites that display mostly text and little fancy stuff, it might even be enough to serve the purpose alone.
Because the CMS might be just as important as the browser in creating an adaptive website, the server-side components must also be capable of enhancing the CMS. This happens to be true of the next four server-side techniques we’ll look at.
In my own experience, avoiding the need for some sort of server-side device detection has proven difficult. A few tools are available for device detection. The WURFL-powered device-detection repository (DDR) provided by ScientiaMobile has been around the longest and is the basis for much of the server-side optimization in our project. However, even though ScientiaMobile provides an API to the WURFL database, we needed more flexibility and, so, built a RESTful API on top of it.
The device database can then be queried like this:
GET http://example.com/ddr/c/<WURFL capability here>
And the answer is returned in JSON format (asking for the device model):
HTTP/1.1 200 OK
Content-Type: application/json
{"model_name":"iPhone"}With this simple API, device detection can easily be used directly from the browser, using AJAX, or from the server-side programming language. Moreover, it can easily be used with popular feature-detection frameworks such as Modernizr.
The nice thing about doing this server side is that the same information is available both client side and server side (including the CMS). Furthermore, it also provides a way to store “tacit knowledge,” defining how the client should tackle certain aspects of the website. Tacit knowledge can be stored as custom capabilities and accessed the same way as any standard WURFL capability. The service is accompanied by a JavaScript library that appends additional client-side detected data. This helps the service make sense of a request when traditional analysis of the HTTP header is insufficient.
Today, the type of markup is not important, and most of the adaptation has moved into the CSS, JavaScript and images. In general, there is no need to serve any markup other than plain HTML5. The only exception is certain markets around the world in which feature phones, rather than smart devices, are dominant. In these cases, we need enough flexibility to handle these devices by serving a particular markup such as XHTML MP. The device-detection service will provide that.
As traffic from mobile devices increases rapidly, caching and content delivery networks (CDN) become keys part of the value chain. Adapting the markup to each device type or user agent would lead to “cache pollution,” which basically means that the cache is too big to make any difference. Keeping the markup of a page as static as possible across devices is key. As mentioned, most optimization in modern browsers happens in CSS and JavaScript. Cache pollution is a relevant issue for those resources, too, but less critical because CSS and JavaScript are easier to cache in the browser and are also typically generic to the website (i.e. the whole website uses the same CSS, so the file needs to be cached only once to be served to all pages on the website).
Media queries in CSS are one of the key parts of RWD. They are also one of the page resources with the most overhead when it comes to excess data downloaded. A mobile phone will download and process styles meant for desktop devices, which can have a detrimental impact on speed and user experience. Of course, well-designed CSS will minimize the issue, but more can be done to reduce CSS overhead.
For this project, we decided to do two things:
To illustrate the first point, styles in the following media query would not be served to an iPhone because the viewport would never be as wide as 1200 pixels.
@media screen and (min-width: 1200px) {
/* styles here */
}This requires a slightly different way of thinking and must, of course, be used with caution because breakpoints might never reach the client. Hence, CSS architecture is important.
The second illustrates the more powerful side of this, where device capabilities become media features:
@media screen and (pointing-method: touchscreen) {
.button{
padding:1em;
}
}The above adds some extra padding to buttons to make them easily touchable on touchscreens. Another, perhaps more useful, example is the handling of fonts in CSS:
@media screen and (font-face: true) {
@font-face {
font-family: 'Rambla';
font-style: normal;
font-weight: 400;
src: local('Rambla'), local('Rambla-Regular'), url(http://themes.googleusercontent.com/static/fonts/rambla/v1/4oKK3Z-EimNu4ISiv21vMuvvDin1pK8aKteLpeZ5c0A.woff) format('woff');
}
}Thus, all capabilities defined in WURFL are available for querying. Custom capabilities can also be added to the system to be made available as media features, too. Again, it’s a different way of thinking about styling. But it’s very powerful, especially for handling browser bugs, “undetectables” and “false positives” from feature detection (which are pretty annoying when they happen), and third-party content. Tests we performed indicated that up to two thirds of the data could be saved using this technique.
To comply with the requirements of the project, we decided to implement it in the markup like this:
<link
href="http://example1.com/css/http://example2.com/path/style.css"
rel="stylesheet"
type="text/css" />In this snippet, the service executing the media queries lives at http://example1.com/css/, and proxies the CSS located at http://example2.com/path/style.css, and then executes, caches and returns the CSS needed by the client.
Image optimization has been a hot potato lately. Until standards and support are established, and given that polyfills are not an option, the best way to optimize images is still to resize and prepare them server side.
The principle of image resizing is similar to CSS and has been proven to work with TinySrc (now Sencha.io):
<img src="http://example.com/img/http://farm9.staticflickr.com/8154/7705240114_fdc69e5882_k_d.jpg" alt="Butterfly" />In this example, the service will download and resize the image according to the screen size of the requesting device, and then cache and serve it to the client.
Being able to specify a size is also handy:
<img src="http://example.com/img/px_320/http://farm9.staticflickr.com/8154/7705240114_fdc69e5882_k_d.jpg" alt="Butterfly" />But this is not very responsive. This is one of those times when we need to combine client-side feature detection with server-side logic.
Below is an example of a JavaScript add-on defining different breakpoints and communicating this to the server through a cookie.
if (vpw >= 1024) {
vpw = 1024; //viewport
bp = "w"; //breakpoint for current viewport
} else if (vpw >= 768) {
bp = "m";
} else {
bp = "n";
}Then, we instruct the resizing service to behave differently according to the current breakpoint. In the image URL in our markup, we state that for breakpoint w, we want an image scaled to 80% of the viewport’s width. For breakpoints m and n, the values are 60 and 40%, respectively.
<img src="http://example1.com/img/vpw_768/bp_m/pc/w_80/m_60/n_40/http://farm9.staticflickr.com/8154/7705240114_fdc69e5882_k_d.jpg" alt="Butterfly" />High-DPI screens are also supported through the @ notation:
<img src="http://example.com/img/px_300/@_2/http://farm9.staticflickr.com/8154/7705240114_fdc69e5882_k_d.jpg" alt="Butterfly"/>As noted by Daan Jobsis, a high-resolution image does not necessarily entail a ton of data, because the image could be compressed much more than a low-resolution image without a visible loss in quality.
When addressing these issues, we noted that some tasks are “compile time” and others are “runtime.” Runtime tasks typically perform device detection on the server side to optimize something for a particular device or browser’s capability. Compile-time optimization handles the preprocessing of images, the minification of JavaScript, the preprocessing of Sass and LESS and so on. This can easily be implemented as Git hooks. It enables an alternative workflow for Web developers, which might be more relevant for some, depending on the server’s configuration and architecture.
By using Git, the CSS, JavaScript and images (and even the page itself) can be pushed to a host (e.g. static.example.com) where static content would be served from. The static resources would, of course, be optimized runtime as well to enable the server-side media queries and image resizing. This way, the extra roundtrip for fetching the resource, as described above, is avoided, too.
This approach might seem to be a trivial detail at first, but if you think of it like a CDN or a cache for static content, it becomes very powerful. Suddenly, the cache becomes intelligent. You can perform tasks when pushing to the cache (compile time) and also do runtime optimization for the device or browser.
To illustrate the findings, I have made a demo based on one of the examples that comes with Twitter Bootstrap and that puts the server-side components to work. The demo is very simple, and much more adaption of Bootstrap should be done, but it illustrates the findings well.
The diagram below shows the distribution of different content types tested in a desktop browser and on an iPhone with Safari. The most obvious difference is the savings we get when optimizing images.
Distribution of content types
The overall result is that we can definitely save time and money by letting the server help the client with adapting the content and presentation:
| Desktop | iPhone | |
|---|---|---|
| Page size | 927.1 KB | 338.8 KB |
| Rendering time (onload) | 6.6 seconds | 4.64 seconds |
The page for an iPhone is only 37% of the total page weight of a desktop client. The page also loads faster on the iPhone. It is not the fastest page to begin with, but a 30% increase in speed is a good start.
Yes, many factors come into play that can influence the tests’ results, but the tests prove that knowing who you are talking to at the other end pays off.
With this approach, we think we have been successful in designing a system that solves the current issues involved in getting the Web to work on different devices as well as in providing Web developers with useful tools to support their goals. The server can definitely improve the performance of RWD and other client-side techniques on mobile devices!
As standards emerge and as devices and networks improve, some issues will disappear, but new ones will pop up as the Web becomes more diverse. Handling diversity is a question not so much of whether to do things server side or client side, but of how to make the whole value chain as intelligent and adaptable as possible to prepare for the unknown — all the way from creating the content to caching to rendering in the browser.
During the project, we became so excited by the results and possibilites that we decided to make the tools available to Web developers out there. Because the project is still ongoing, we haven’t launched yet, but if you think the approach described here is worth a try, you can sign up at WhateverWeb to get early access. (It’s free, but we’d just like you to tell us what you think.)
(al) (ea)
© Jon Arne for Smashing Magazine, 2013.
]]>Sol Voltaics plans to make a nanowire-laden ink to boost solar panel efficiency using a rapid manufacturing process.
Ink filled with microscopic semiconductors called nanowires could make solar power cheaper by boosting the efficiency of solar panels by 25 percent, without adding much cost to manufacturing, says Sol Voltaics, a startup that has raised $11 million, and which this week announced its intention to commercialize the ink.
]]>
The elections for both the IEEE Undergraduate Student Branch and IEEE Graduate Student Branch Executive Boards have been scheduled for Friday, April 19th, 4.00pm to 5.00pm, room TBA. This is our regular meeting time. Below you will find more information on the election process, including the procedure to run for an Officer position.
IEEE Undergraduate Student Branch Officer positions include the following.
IEEE Graduate Student Branch Officer positions include the following.
To run for one of the above positions you must be a grad/undergrad student in good academic status, be subscribed to our mailing list, and send me (Sorry, you need javascript to view this email address. ) a small description (no more than 100 words) about you and why should other members vote for you, no later than next Thursday, April 11th, by 12.00pm (noon). You can only run for one position.
These descriptions will be compiled and sent out to the entire mailing list no later than the following Friday, April 12th. Each candidate will be given two minutes during that Friday's meeting to make a brief speech.
The election process will be supervised by our advisor, Dr. Choa.
IMPORTANT
Please come and vote on the 19th to ensure that your voice is heard, and consider running for one of the positions. If you have any concerns or questions about the election process, please let Jorge Teixeira (Sorry, you need javascript to view this email address. ) know ASAP.
On behalf of the UMBC IEEE GSB and UMBC IEEE USB Executive Boards,
UMBC IEEE Student Branch, Chair
Jorge Teixeira
A new Washington Times commentary critiquing government contracting programs for minority- and women-owned firms references testimony by UMBC professor George La Noue on why federal contacting preferences should be reexamined. La Noue is an expert on education policy, constitutional law and policy, and public procurement policy, and is a frequent witness in Congressional testimony.
Nicole Else-Quest, assistant professor of psychology, is the author of an April 9 post in the “Huffington Post” blog entitled “Contextualizing the Conversation on Women and STEM.”
Else-Quest is the lead author of a recent study that found that female students perform as well as males in STEM classrooms, but report less confidence about their abilities. It also found that Asian American students outperform other ethnic groups.
In her piece for the Huffington Post, she argued that “the national conversation about women and STEM cannot progress until it considers gender within the context of other social identity variables, such as ethnicity, class, and immigration.”
“We don’t think of ourselves as only having gender or only having race. We think of ourselves as multifaceted and complex individuals – because we are multifaceted and complex individuals,” she writes.
]]>