BlogmyQuery – BMQ

For most of us, one of the first tools we use for drawing pictures (beyond the crayons and finger paint of our early days) is a pencil. Be it a lead based or colored pencil, these analog artist tools are still a big staple among artists and designers alike. As designers many of us keep our handy notebooks and pencils within reach for the beginnings of any new designs or projects that come our way. Today’s inspirational collection may just have you reaching for that notebook and pencils before its done.

In this post you will find numerous stunning examples of pencil drawings that will have your jaws on the floor. Shocked that many of these imaginative pieces were created with colored or lead based pencils alone. Such amazing artistry on display, that we are sure it will delight and inspire all of our readers.

Analog Art

Lady of Spiders by TeSzu

Stone Face by fabaorts

Small Blessings by Cataclysm-X

Please hold my hand tightly by hellobaby

Vengeance of a Bride by lehanan

Decay by MelloLover

Mysterious one behind the shadows by PearlEden

Pearls by witchi1976

The Remnant by shimoda7

Windswept by imaginee

Dark Hope by Zindy

Fangs III, pencil by Panthera11

Jean Harlow Minimal by Ileana-S

Katiebloo by TeSzu

Buho Cornudo by faboarts

Metamorphosis by Cataclysm-X

Hold your hand by hellobaby

Voulez-vous…? by lehanan

Complementary by Loonaki

Feathered eye by witchi1976

Waiting by shimoda7

The Face Of David by imaginee

It went away by Zindy

Cat 3 by tajus

In Solitude… by Ileana-S

Unspoken Words by Snow-Owl

Yuri by KLSADAKO

Wroclaw Ostrow Tumski by TeSzu

Basset hound by faboarts

You May Kiss The Bride by imaginee

Elegancy by Cataclysm-X

My dear. let me show you by hellobaby

Childhood in Minor by lehanan

Mirror of Earth by PearlEden

Braid by witchi1976

Can’t turn back time by shimoda7

Portrait of Dakota by imaginee

Unleash the butterflies by Zindy

Self Portrait with Tools of Trade by Ileana-S

Playful curls – Pencil drawing by Regius

That’s All, Folks

That finishes up the collected works, but it doesn’t have to end there. Now we turn the comment section over to you so you can fill us in on your favorites from the showcase. Do you know of some other pencil drawings that would have made a nice addition to the list? Provide us a link so other readers can check them out.

(rb)

In my nearly two decades as an information architect, I’ve seen my clients flush away millions upon millions of dollars on worthless, pointless, “fix it once and for all� website redesigns. All types of organizations are guilty: large government agencies, Fortune 500s, not-for-profits and (especially) institutions of higher education.

Worst of all, these offending organizations are prone to repeating the redesign process every few years like spendthrift amnesiacs. Remember what Einstein said about insanity? (It’s this, if you don’t know.) It’s as if they enjoy the sensation of failing spectacularly, publicly and expensively. Sadly, redesigns rarely solve actual problems faced by end users.

I’m frustrated because it really doesn’t have to be this way. Let’s look at why redesigns happen, and some straightforward and inexpensive ways we might avoid them.

The Diagnostic Void

Your users complain about your website’s confounding navigation, stale content, poor usability and other user experience failures. You bring up their gripes with the website’s owners. They listen and decide to take action. Their hearts are in the right place. But the wheels quickly come off.

Most website owners don’t know how to diagnose the problems of a large complex website. It’s just not something they were ever taught to do. So, they’re put in the unfortunate, uncomfortable position of operating like country doctors who’ve suddenly been tasked to save their patients from a virulent new pandemic. It is their responsibility, but they’re simply unprepared.

Sadly, many website owners fill this diagnostic void — or, more typically, allow it to be filled — with whatever solution sounds best. Naturally, many less-than-ethical vendors are glad to dress up their offerings as solutions to anyone with a problem — and a budget. The tools themselves (search engines, CMS’, social apps) are wonderful, but they’re still just tools — very expensive ones, at that — and not solutions to the very specific problems that an organization faces. Without proper diagnostics to guide the configuration of tools, any resulting improvements to the user experience will be almost accidental.

Sometimes design agencies are brought in to fill the diagnostic void. And while not all agencies are evil, a great many follow a business model that depends on getting their teams to bill as many hours as they can and as soon as possible. Diagnostics can slow the work down (which is why clients rarely include a diagnostic phase in their RFPs). So, many agencies move to make a quick, tangible impression (and make their clients happy) by delivering redesigns that are mostly cosmetic.

A pretty face can last only a few years, but by then the agency is long gone. Invariably, the new owner wishes to make their mark by freshening or updating the website’s look. And another agency will be more than happy to oblige. Repeat ad nauseam, and then some.

Oh, and sometimes these redesigns can be pricey. Like $18 million pricey.

See why I’m so grouchy?

Forget the Long Tail: The Short Head Is Where It’s At

Whether you’re a designer, researcher or website owner, I’ve got some good news for you: diagnostics aren’t necessarily difficult or expensive. Better yet, you’ll often find that addressing the problems you’ve diagnosed isn’t that hard.

And the best news? Small simple fixes can accomplish far more than expensive redesigns. The reason? People just care about some stuff more than they care about other stuff. A lot more. Check this out and you’ll see:

This hockey-stick-shaped curve is called a Zipf curve. (It comes from linguistics: Zipf was a linguist who liked to count words… but don’t worry about that.) Here it is in dragon form, displaying the frequency of search queries on a website. The most frequently searched queries (starting on the left) are very, very frequent. They make up the “short head.� As you move to the right (to the esoteric one-off queries in the “long tail�), query frequency drops off. A lot. And it’s a really long tail.

This is absolutely the most important thing in the universe. So, to make sure it’s absolutely clear, let’s make the same point using text:

Query’s rank	Cumulative %	Query’s frequency	Query
1	1.40%	7,218	campus map
14	10.53%	2,464	housing
42	20.18%	1,351	web enroll
98	30.01%	650	computer center
221	40.05%	295	msu union
500	50.02%	124	hotels
7,877	80.00%	7	department of surgery

In this case, tens of thousands of unique queries are being searched for on this university website, but the first one accounts for 1.4% of all search traffic. That’s massive, considering that it’s just one query out of tens of thousands. How many short-head queries would it take to get to 10% of all search traffic? Only 14 — out of tens of thousands. The 42 most frequent queries cover over 20% of the website’s entire search traffic. About a hundred gets us to 30%. And so on.

It’s Zipf’s World; We Just Live in It

This is very good news.

Want to improve your website’s search performance? Don’t rip out the search engine and buy a new one! Start by testing and improving the performance of the 100 most frequent queries. Or, if you don’t have the time, just the top 50. Or 10. Or 1 — test out “campus mapâ€� by actually searching for it. Does something useful and relevant come up? No? Why not? Is the content missing or mistitled or mistagged or jargony or broken? Is there some other problem? That, folks, is diagnostics. And when you do that with your website’s short head, your diagnostic efforts will go a very long way.

The news gets better: Zipf is a rule. The search queries for all websites follow a Zipf distribution.

And the news gets even jump-up-and-down-and-scream-your-head-off better: Zipf is true not only for your website’s search queries. Your content works the same way! A small subset of your website’s content does the heavy lifting. Much of the rest has little or no practical value at all. (In fact, I’ve heard a rumor that 90% of Microsoft.com’s content has never, ever been accessed. Not once. But it’s a just a rumor. And you didn’t hear it here.) Bottom line: don’t redesign all of your content — focus on the stuff that people actually need.

You’ll also see a short head when it comes to your website’s features. People need just a few of them; the rest are gravy.

And there’s more. Of all the audience types that your website serves, one or two matter far more than the others. What tasks do those audience types wish to accomplish on your website? A few are short-head tasks; the rest just aren’t that important.

As you can see, the Zipf curve is everywhere. And fortunately, the phenomenon is helpful: you can use it to prioritize your efforts to tweak and tune your website’s content, functionality, searchability, navigation and overall performance.

Your Website Is Not A Democracy

When you examine the short head — of your documents, your users’ tasks, their search behavior and so forth — you’ll know where to find the most important problems to solve. In effect, you can stop boiling the ocean…

… and start prioritizing your efforts to diagnose and truly solve your website’s problems.

Now, let’s put these short-head ideas together. Below is a report card for an academic website that starts with the short head of its audience:

In other words, of all the audience types this university website has, the three most important are people who might pay money to the university (applicants,) people who are paying money now (students) and people who will hopefully pay money for the rest of their lives (alumni). How do we know they’re the most important audiences? We could go by user research; for example, the analytics might suggest that these audiences generate more traffic than anyone else. Or perhaps the university’s stakeholders believe that these are the most important ones in their influence and revenue. Or some combination of both. Whatever the case, these three audiences likely swamp all other segments in importance.

Then, we would want to know the short-head tasks and information needs of each audience type. We might interview stakeholders to see what they think (column 2). And we might perform research — user interviews and search analytics, for example — to find out what users say is most important to them (column 3).

Of course, as the good folks at xkcd demonstrate, stakeholders and users don’t always see things the same way:

That’s why talking to both stakeholders and users is important. And once you’ve figured out the short head for each, you’ll need to earn your salary and, through some careful negotiation, combine your takes on each audience type’s needs. That’s what we’ve done in column 4.

Finally, in column 5, we’ve tested each task or need and evaluated how well it works. (Because it’s a university-related example, letter grades seemed appropriate.) You can do this evaluation in an expensive, statistically significant way; but really, enough research is out there to suggest that you don’t need to spend a lot of time and money on such testing. More importantly, these needs and tasks are often fairly narrow and, therefore, easy to test.

So, after testing, we can see what’s not going well. Finding information on “mentoring� is hard for applicants. And current students have a devil of a time when they “look up grades.�

Now we’re done diagnosing the problems and can begin making fixes. We can change the title of the “Paired Guidance Program� page to “Mentoring.� We can create a better landing page for the transcript application. The hard part, diagnostics, is out of the way, and we can now fix and tune our website’s performance as much as our resources allow.

From Project To Process To Payoff

These fixes are typically and wonderfully small and concrete, but because they live in the short head, they make a huge and lovely impact on the user experience — at a fraction of the cost of a typical redesign.

The tuning process itself is quite simple. It’s what we used to arrive at the report card below:

If you repeat this simple process on a regular basis — say, every month or quarter — then you can head off the entropy that causes fresh designs and fresher content to go rotten. Thus, the redesign that your organization has scheduled for two years from now can officially be canceled.

Your website’s owners ought to be happy about all this. And you should be, too: rather than tackling the project of getting your website “rightâ€� — which is impossible — you can now focus on tweaking and tuning it from here on out. So, forget redesigns, and start owning and benefiting from a process of continual improvement.

Special Thanks – Illustrations

Eva-Lotta is a UX Designer and Illustrator based in London, UK where she currently works as an interaction designer at Google. Besides her daytime mission of making the web a more understandable, usable and delightful place, she regularly takes sketchnotes at all sorts of talks and conferences and recently self-published her second book. Eva-Lotta also teaches sketching workshops and is interested in (something she calls) visual improvisation. Exploring the parallels between sketching and improvisation, she experiments with the principles from her theater improvisation practice to inspire visual work.

(al)

---

© Louis Rosenfeld for Smashing Magazine, 2012.

I see more and more devices that have a pixel ratio bigger than 1.5, even 2. My Galaxy Nexus for example has a pixel ratio of 2 and so do the latest versions of the iPhone and iPad. Retina display seems to be the next evolution and next challenge for us as designers.

Native mobile app designers have already learned how to take advantage of those devices with high pixel ratios to display bigger images with better quality, so as to enhance user experience. They are used to creating the images in both normal and retina @2x sizes for the iPhone, and creating 4 sets of drawables in 4 different sizes for Android devices.

With the iPad 3 also having retina display, it is definitively something that will be harder to avoid from now on. In this article, you will see how to use some CSS3 tricks in the field of image replacement to serve images with better quality to those high resolution devices.

Story Behind the Code

It all began when I was creating a jQuery Mobile application for the iPhone. The idea was to make a full HTML5 jQueryMobile app, and to embed it in a “native shell�, using Phonegap.

For this application, I created a bottom tab-bar that was imitating the native iOS tab-bar, and also a header with a logo image in it. Both the header and footer were HTML elements that used image replacement techniques to display the icons and logo.

When I tested the application on the iPhone 4S, I saw that the logo and the icons were highly rasterized and looked pretty ugly.

The Demo

I re-created a fake application page similar to the iOS native style so you can see what is going on. Whether you have a retina device or not, you can test it here with your phone. You can see the demo here. You can also download the code here.

As I said, if you load the page on a non retina device, it will look good. If you load it on a retina device, the images get rasterized.

This is due to the pixel ratio being 2, so the image is multiplied by two and stretched by the device, creating this unclean rendering. Here are some screenshots of the demo on iPad 3, iPhone 4 and Galaxy Nexus with the images being rasterized:

Galaxy Nexus:

iPhone 4:

iPad 3:

CSS Image Replacement Techniques

In this demo, I used different techniques for replacing images that will have varying consequences when we will want to change for retina images.

The first image we replace is in the logo, being sure to only set the height of the element. The HTML looks like this:

<div class="ui-header"> <h1> My logo </h1></div>

The CSS like this:

.ui-header h1{

color:#fff;

display: block;

outline: 0 none !important;

overflow: hidden;

margin:0;

text-align: center;

text-overflow: ellipsis;

white-space: nowrap;

text-indent:-9999px;

background:url(img/logo.png) no-repeat center center;

height:33px;

}

Again, what’s important here is that we give it height, but no width.

The second technique is to use the delete button. We want to keep the text for this one, so we will add the icon in the :before pseudo class. The HTML looks like this :

<p> <a href="#"> Delete item </a> </p>

And the CSS code like this:

.delete:before{

content: " ";

display:block;

width:20px;

height:20px;

position:absolute;

left:6px;

background:url(img/delete.png) no-repeat;

}

Note that in this case, we gave the element both a width and a height but no padding.

The next element to which we want to add an icon is the download button. The HTML looks like this:

<p> <a href="#"> Download </a></p>

And the CSS like this:

.download {

background:rgb(222, 227, 232) url(img/nuage.png) no-repeat 8px 6px;

border:1px solid rgb(199, 206, 212);

padding: 25px 0 25px 120px;

font-size:20px;

color:rgb(144, 160, 176);

text-shadow: 0 1px 1px rgb(239, 242, 245);

}

This is what we will call the third technique: assigning some padding, but no height or width. You will understand why below.

For the footer however, we also assign a width and height for the element, padding too. The HTML:

<a class="bubble button" href="#"> bubble </a>

The CSS:

.ui-footer .button{

background-color:rgba(187, 185, 185, 0.2);

border:1px solid rgb(22, 22, 22);

box-shadow: 0px 1px 2px rgba(22, 22, 22, 0.5) inset ;

text-indent:-9999px;

padding:10px 15px;

width:40px;

height:40px;

background-position: center center;

background-repeat:no-repeat;

margin: 0 5px;

}

.bubble{

background-image:url(img/bubble.png);

}

At this point we have different case scenarios for the image replacement that will load non retina images for all devices, for now.

Media Queries Pixel-Ratio to the Rescue

The next idea was then to find a solution to make those devices load better quality images. I remembered the media query device-pixel-ratio (vendor prefix needed). I never used it before, and decided to give it a try. You will need some vendor prefixes here (Mozilla is the strangest one).

The idea was pretty simple: I decided to try to serve those devices an image that would have twice the size of the desktop one. I chose a @2x notation for the retina image because I’m used to doing so when I create images for native iOS apps. I ended up doing something like this:

@media only screen and (-webkit-min-device-pixel-ratio: 2),

only screen and (min--moz-device-pixel-ratio: 2),

only screen and (-o-min-device-pixel-ratio: 2/1),

only screen and (min-device-pixel-ratio: 2) {

#myelement{

background:url(myicon@2x.png) no-repeat;

}

}

You would think that this works good. True, the retina image is loaded, but the problem is that the image is now twice the size. Still not displaying properly. Here is what it looked like on my Galaxy: the icons are nice and sharp, but not quite right.

Background-Size Property Lends a Hand

Now that we have the high resolution images loading, we need to ensure they are the right size. To do this, we will use the super useful CSS3 background-size property that is actually able to resize backgrounds as needed. You can either use pixel properties for width first then height, use percentages, or set the value to “auto�.

It’s simple to see it in the code. (Note that I used the id #retina for the demo purpose to only target the second part of the demo, but you can of course omit it in your code)

For the header button you remember that we did set the height but not the width, to do the trick here, we will then set the background height to the same value (we can leave the width at auto).

#retina .ui-header h1{

background:url(img/logo@2x.png) no-repeat center center;

-webkit-background-size: auto 33px ;

-moz-background-size: auto 33px ;

background-size: auto 33px ;

}

For the delete button technique it’s a bit easier, since we did set both width and height AND since it has no padding, we can set the value to 100% for each, meaning that the icon will use the whole container space:

#retina .delete:before{

background:url(img/delete@2x.png) no-repeat;

-webkit-background-size: 100%  100% ;

-moz-background-size: 100%  100% ;

background-size: 100%  100% ;

}

For the download button, it gets trickier. Since we did not give it any width or height, we will then have to set the exact sizes of the non retina image for this one:

#retina .download {

background:rgb(222, 227, 232) url(img/nuage@2x.png) no-repeat 8px 6px;

-webkit-background-size: 70px 68px ;

-moz-background-size: 70px 68px ;

background-size: 70px 68px ;

}

For the footer icons, we did set width and height, but the element has some padding. So here we will have to set at least one of the two values to make it work:

#retina .bubble{

background-image:url(img/bubble@2x.png);

}

#retina .loupe{

background-image:url(img/loupe@2x.png);

}

#retina .folder{

background-image:url(img/folder@2x.png);

}

#retina .ui-footer .button{

-webkit-background-size: 40px auto ;

-moz-background-size: 40px auto ;

background-size: 40px auto ;

}

And this is what it now looks like:

What About HTML Images?

I only base this article on the CSS images, but of course there are also images directly in the HTML. For this, you will have to take a look at some responsive image techniques. So far I tested retina.js and have to admit that it’s pretty simple to use, you just have to put a @2x image in the same folder as the normal one and include the script. There is also the Retina Images plugin that seems to do the same job, but needs more server side configuration.

Limitations and Conclusion

As you can see, each case is different and you will have to play with the background-size values to get exactly what you want. The other limitation would be browsers downloading two images for this hack: first the normal, then the retina. I’m not an expert in this particular domain and did not run tests for the demo so if you want to, feel free to do and you can post the results I’m curious to know the browser used and if the images are downloaded twice.

The techniques used in this article are based on a lot of CSS3 code, so might not be supported by all browsers. Also, having to create all the images in two sizes can be hard for maintaining the code, and take more space on the server side. So you will have to think carefully before you use such techniques. Forcing devices to load images twice the size, and then to resize them can also be bandwidth consuming.

In conclusion, I would advise that even though this is a good technique for creating sleek pixel perfect nice interface for devices that support it, there are considerations to be made before using such a technique. Naturally, this won’t be the solution for everyone.

Going further

If you are interested in displaying nice icons without having to create the files twice, you also can take a look at the iconic font technique and at SVG images. There is also this article you can look to, but here again, this is not widely supported.

(Credits for the monochromatic icon set)

(rb)

I sat down for a while with the excellent PeepCode folks and recorded a Play by Play — a real time video of me solving a design problem. A bit terrifying, a bit fun. Check it out if you’d like to see me bumble around.

Responsible responsive design demands responsive images—images whose dimensions and file size suit the viewport and bandwidth of the receiving device. As HTML provides no standard element to achieve this purpose, serving responsive images has meant using JavaScript trickery, and accepting that your solution will fail for some users. Then a few months ago, in response to an article here, a W3C Responsive Images Community Group formed—and proposed a simple-to-understand HTML picture element capable of serving responsive images. The group even delivered picture functionality to older browsers via two polyfills: namely, Scott Jehl’s Picturefill and Abban Dunne’s jQuery Picture. The WHATWG has responded by ignoring the community’s work on the picture element, and proposing a more complicated img set element. Which proposed standard is better, and for whom? Which will win? And what can you do to help avert an “us versus them� crisis that could hurt end-users and turn developers off to the standards process? ALA’s own Mat Marquis explains the ins and outs of responsive images and web standards at the turning point.