    
|
|
|
When students have the scholarship support they need, they can do AMAZING things. And during the month of June, we’re working hard to help students do just that — make the most of their time at UMBC, and change the world for the better, with the aid of scholarships. Our aim? To raise enough money to award 30 scholarships of $1,000. It’s a big goal, but you can help us reach it, and when you do, you’ll be helping students in need.
Today we’re featuring 2013 valedictorian and scholarship recipient Asif Majid ’13, interdisciplinary studies, who this fall is bound for Georgetown University to study conflict resolution. While at UMBC, Asif (a Sondheim Public Affairs Scholar) not only wrote a play about Moroccan social justice issues while studying abroad in Morocco, he also participated in Model UN and served as a hand drummer in UMBC’s improvisational world music band and principal timpanist for the UMBC Symphony Orchestra.
Q: What did it mean to you and your family to be able to rely on scholarship support during your time at UMBC?
A: Coming out of high school, one of my main considerations in choosing a university to attend was financial. Simultaneously, I was concerned with having a sense of community, as close-knit as possible, while at UMBC. As a Sondheim Public Affairs Scholar, the financial support that I received from the program and the community support I received from my fellow scholars were essential parts of my UMBC experience.
Q: Why did you choose UMBC?
A: Rather than me choosing UMBC, I think that UMBC chose me. Before and during my high school years, my father taught in the Mechanical Engineering Department, my sister was a Meyerhoff Scholar and Interdisciplinary Studies major, and my mother volunteered with the Meyerhoff Parents’ Association. UMBC has been a constant presence in my life, and it seemed a natural fit when it came time to choose an undergraduate institution. Receiving financial support from the school only sweetened the deal.
Q: We know that students who receive the support they need can do amazing things at UMBC. What are you most proud of accomplishing in your time at UMBC?
A: Though UMBC has afforded me many opportunities and given me support to be successful in many arenas, I would say that I am most humbled and honored to have achieved excellence within the Interdisciplinary Studies Department (INDS). Designing my own major, conducting independent research through my capstone and social justice theatre project, integrating a study abroad experience into my undergraduate career, and making history as the first valedictorian from INDS are simply my way of saying thank you to the exceptional department that has been my home for the past four years.
Q: How did it feel to be able to address your classmates as valedictorian?
A: It is an impossible task to speak for anyone else, let alone to represent the experiences of thousands of students at a university as diverse as UMBC. Holding fast to the idea that any good valedictory address is not about the valedictorian but about the graduates as a whole, I chose to speak in terms of ideas and principles such as risk-taking and remembering our origins. Each graduate has a unique experience that is theirs alone, and I wanted to acknowledge that journey.
Q: I understand you’re planning on studying conflict resolution at Georgetown. Where do you hope your studies take you?
A: I feel that my life lines up alongside the motto of The Honors College: “Learning for Living.” Infused with such an idea after my time at UMBC, I aim for my studies to propel me in the direction of being a conflict transformation scholar-practitioner. This will involve working in the intersections of the performing arts, experiential education, conflict transformation, and humanitarian emergencies while also thinking, teaching, and writing about how to improve the conditions of others in conflict zones. For me, the convergence of learning and living is an exciting interstitial space that I believe will characterize my future.
The following is a guest post by Les James. Like many of us, Les has been gunning for a solution to responsive images that works for him. In this article he shares a technique he found where he can pass "named" media queries from CSS over to the JavaScript, which uses those names to swap out the image for the appropriate one for that media query. And even automate the process with Sass. HTML purists may balk at the lack of true src on the image, but at this point we gotta do what we gotta do.
Current proposed responsive image solutions require that you inline media query values into HTML tags.
<picture>
<source media="(min-width: 45em)" src="large.jpg">
<source media="(min-width: 18em)" src="med.jpg">
<source src="small.jpg">
<img src="small.jpg" alt="">
</picture>This is a problem for me. I like my media queries in one spot, CSS. The above example doesn't feel maintainable to me, and part of that might be due to my approach to RWD. I use the Frameless grid approach to creating layouts. I tell Sass how many columns I want in a layout and it generates a media query to fit it. What this means is that I only think in column counts and I actually have no idea what the actual values of my media queries are.
When adapting this approach to responsive images, I needed a way to provide meta data around my breakpoints. So when I create a breakpoint, I give it a label. I've recently been a fan of labels like small, medium and large but the labels could be anything you want. The point is that you name your breakpoints with something meaningful. The goal is to pair those names to matching sources defined in my HTML. The first step is to format our label into something JavaScript can parse.
When I create a breakpoint I call upon a Sass mixin I created. The column count creates a min-width media query to fit that column count. The label gives a name to our media query.
@include breakpoint(8, $label: "medium") {
/* medium size layout styles go here */
}The breakpoint mixin passes that label to a function which formats it into a string of JSON.
@function breakpoint-label($label) {
@return '{ "current" : "#{$label}" }';
}Now that we have our label converted to JSON, how do we get it into our CSS? The natural fit for a string is CSS generated content. I use body::before to hold my string because it's the least likely spot for me to actually use for display on the front end. Here is how the label finds its way into CSS from my breakpoint mixin.
@if($label) { body::before { content: breakpoint-label($label); } }Unfortunatly I have to support older browsers and they will have trouble reading our CSS generated content with JavaScript. So we have to place our JSON in one more spot to gain further compatibility. For this I'm going to add our JSON as a font family to the head.
@if($label) {
body::before { content: breakpoint-label($label); }
.lt-ie9 head { font-family: breakpoint-label($label); }
}Our layout label is now sitting in a JSON string in our CSS. To read it with JavaScript we turn to our friend getComputedStyle. Let's create a function that will grab our JSON and then parse it.
function getBreakpoint() {
var style = null;
if ( window.getComputedStyle && window.getComputedStyle(document.body, '::before') ) {
style = window.getComputedStyle(document.body, '::before');
style = style.content;
}
return JSON.parse(style);
}For browsers that don't support getComputedStyle we need to throw in a little polyfill and grab the head font family instead.
function getBreakpoint() {
var style = null;
if ( window.getComputedStyle && window.getComputedStyle(document.body, '::before') ) {
style = window.getComputedStyle(document.body, '::before');
style = style.content;
} else {
window.getComputedStyle = function(el) {
this.el = el;
this.getPropertyValue = function(prop) {
var re = /(\-([a-z]){1})/g;
if (re.test(prop)) {
prop = prop.replace(re, function () {
return arguments[2].toUpperCase();
});
}
return el.currentStyle[prop] ? el.currentStyle[prop] : null;
};
return this;
};
style = window.getComputedStyle(document.getElementsByTagName('head')[0]);
style = style.getPropertyValue('font-family');
}
return JSON.parse(style);
}There is a major problem with our function right now. Our JSON is passed as a string which means that it is wrapped in quotes, but what kind of quote depends on which browser you are using. WebKit passes the string wrapped in single quotes. Firefox passes the string wrapped in double quotes which means that it escapes the double quotes inside of our JSON. IE8 does something really wierd and adds a ; } to the end of our string. To account for these inconsistancies we need one more function to normalize our JSON before we parse it.
function removeQuotes(string) {
if (typeof string === 'string' || string instanceof String) {
string = string.replace(/^['"]+|\s+|\\|(;\s?})+|['"]$/g, '');
}
return string;
}Now before parse the JSON in the return of our getBreakpoint function we just pass the string through our removeQuotes function.
return JSON.parse( removeQuotes(style) );JavaScript can now read the label that we defined for each breakpoint. It's trivial at this point to match that label to a responsive image source. Take the following image for example.
<img data-small="small.jpg" data-large="large.jpg">When the active media query is small, we can have JavaScript match that to data-small and set the source of our image to small.jpg. This works great if you've declaired a source for every breakpoint but as you can see in our example we don't have a source defined for medium. This is a very common scenario. The small image can typically work in larger layouts. Maybe the medium layout just added a sidebar and our image size didn't change. So how does JavaScript know to pull the small source when the layout is medium? For this we need ordering.
Every time we create a breakpoint we can store that label in a Sass list. In our breakpoint mixin we can append the label to our list.
$label-list: append($label-list, $label, comma);Assuming that our list defaults to a pre-populated mobile label of small the following breakpoints will create a list of small, medium, large.
@include breakpoint(8, $label: "medium");
@include breakpoint(12, $label: "large");The order you declare your breakpoints in Sass will determine the order of your labels. Let's add this Sass list as an array to our JSON function.
@function breakpoint-label($label) {
$label-list: append($label-list, $label, comma);
@return '{ "current" : "#{$label}", "all": [#{$label-list}] }';
}Now in addition to JavaScript knowing the current breakpoint label it can look at the array we passed and know their order. So if the layout is medium and no matching data attribute is found on our image, JavaScript can find medium in our label array and walk backwards through that array until a matching source is found.
This responsive image solution does something really important for me. By tagging media query values with labels I create flexibility and simplicity. If I change the size of a breakpoint I only have to change it in one place, my Sass. My HTML image sources aren't dependent on the value of my media queries, just their name.
Although I've accomplished this with Sass, it's actually not necessary. You can manually write your JSON string into your media queries, Sass just helps automate the process. Here is a simple Pen that uses pure CSS.
Check out this Pen!
To see a more robust, production quality implementation of this technique check out the code behind my framework Breakpoint.
Please note, if you want your image tags to be valid then stub them with a source like src="data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs%3D" and please, make sure you provide a <noscript> fallback.
My hope for sharing this is that it spurs further discussion and ideas around abstracting the complexities and maintainability of responsive images. I'm curious to hear your thoughts and if you have ways to improve this.
We all stand on the shoulders of giants. Much credit and inspiration for this is due to Jeremy Keith's post Conditional CSS and Viljami Salminen's detectMQ.
Making Sass talk to JavaScript with JSON is a post from CSS-Tricks
]]>|
|
|
|
I ought to know a lot about charities and non-profit organizations. My parents are career missionaries; and I grew up in an environment where everyone I knew was dedicated to improving the lives of others. My family moved around a bit, and I spent my childhood and teen years in several different missionary communities in Canada and Mexico, each of which organized their own charitable endeavors.
In Ontario, it was a literacy program. In Sinaloa, we brought healthier, organic food and donated goods of all kinds to orphanages and daycares in low-income communities. In Jalisco, there’s a free kitchen for the children of a very poor neighborhood, where they can get at least one good meal per day. In Nuevo León, there are good people going to children’s hospitals to try and cheer up the patients and their relatives alike.
As the resident nerd, it often fell to me to create promotional materials and websites for whomever I happened to be working with at the time. After all, these were low-budget operations staffed by few people. Who could afford to hire a professional?
Well, the universe loves a joke: I became a professional.
It isn’t all that different, if you’re doing it right. The same basic principles of design still apply, and you’re still selling something to your users.
That’s right, you’re selling something. All design is about selling. In this case, you’re selling a cause. You’re selling a reason for some people to send money to other people. Only it’s a bit harder sometimes, because most of the time, the people dropping the cash don’t reap any direct benefit. This is one reason why even most of the charitable campaigns on Kickstarter and IndieGoGo offer perks and rewards.
Just like in any other transaction, you have to convince your users that parting with their money, time, or other resources is a good idea. This is never easy, but it’s not impossible either.
I think that every website should be doing this, but in the charity world, transparency is paramount. You want your users to understand, at their first glance at the website, both what it is that you do and what you need from them.
You need to be able to describe — in a maximum of three sentences — who you’re helping, how you’re helping them, and how your users can help you. The rest of the content on the website is only there to support the veracity of your initial statements.
The Community FoodBank of New Jersey provides an excellent example of this principle. Who are they, and whom are they helping? How are they doing it? Your first clue is in the name. How can you help them? The calls to action are right there, including a “donate” button. (That’s important.)
Simple, transparent, and most importantly, obvious.
Out of all of the many, many communication tools we have developed over time, there is one that has never been equaled: the story. Most people see their own lives as one big story, somehow seeing themselves at the center of everything that goes on. We are all protagonists in our own minds.
Because of this natural narrative — this first-person perspective — we connect with stories, and the characters in them, on a level that almost defies reason. Do you want your users to identify with the people you’re trying to help? Tell them a story that they can’t ignore. You have to bring them down into the dark places, through the pain, and then out on the other side.
As a lover of stories myself, I often find myself going over them again and again in my head. I empathize with the pain the characters have gone through. I see the one little plot twist that, had it been explained to the right characters, could have saved them so much pain and heartache. Then, you can tell your users that they can, in fact, change the story. Wow. “Change the story” — somebody steal that from me.
The most memorable website that I have ever seen employing this tactic is Too Young to Wed. They don’t use too many words to tell the stories. Few people have the patience for that anymore. Instead, they use heart-wrenching, compelling imagery to tell the tale.
Don’t ever use stock photos of people. Really… don’t. They already look fake on regular commercial sites. On a charity site, it makes the organization look very scammy. Sadly, there are quite a few scams that claim to be charities, so it’s a valid concern.
As a corollary, don’t use pictures of the volunteers or organization administrators in the design. Sure, you can have some on the “About Us” page, or something of the like — just don’t put them front and center. This isn’t about the volunteers. It’s about helping the people that they help.
As far as imagery goes, you just can’t compete with pictures of real individuals who have real needs. Get a photographer, or go take the pictures yourself if you have to.
Oh, you want examples? Scroll back up and check out Too Young to Wed again, or take a look at Smoking Takes Lives. Right now, they’re going all out and focusing specifically on one individual, and his story, to great effect.
Almost worse than stock photos are staged photos. You know the ones. There’s a bunch of people standing uncomfortably close to fit as many as possible. They’re all wearing death-grins. They may be holding some donated goods aloft. Or maybe one person is passing some food to another person, but they’re both looking at the camera. Then, there was the guy that tried to do all of that and give me the thumbs up while I took the photo.
Don’t let anyone pressure you into using those kinds of photos.
Dealing with charity and non-profit clients can be a bit different. They’re usually very nice people, with all the best of intentions. They’re also often very opinionated. This is especially true if they’re getting the website for free.
Don’t ask me why, but nine times out of ten, people to whom you give free work are much more demanding than the clients who pay you a lot. Maybe they see your time, efforts, and expertise as less valuable, since they’re getting it all for free. Maybe there’s some other reason.
This is not to say you shouldn’t try to help. A reasonable discount is often a good way to go, but try to avoid doing anything for free — even for charity.
The one notable exception, in my experience, is a project I’m actually still working on. I probably can’t give out details just yet, but I’m working with a team. We’re all volunteers from different parts of the world, including our project manager, who does all of the talking with the clients. This has made the experience much smoother overall.
Other than the money issue, you’re likely to run into other, more typical client quirks. In smaller organizations, your client may have done their own newsletters or other promotional materials for a long time. As a result, they might have a tendency to micromanage.
One client actually criticized my work for being “too professional”. They thought having design that looked too good would give people the wrong impression about their organization. You know, the kind of stuff that makes for a good story when it’s all over.
Heck, aside from helping people, a good story almost makes it worth the trouble.
Have you designed for non-profits? What tips would you add? Let us know in the comments.
| PhotoBulk: Batch Photo Editing for Mac – only $4.97! |  |
|
|
|
|
 |
Responsive Web design has transformed how websites are designed and built. It has inspired us to think beyond device classifications and to use media queries to adapt a layout to the browser’s viewport size. This, however, deviates from the hierarchical structure of CSS and characterizes elements relative to the viewport, instead of to their container.
Extensive use of media queries might be the answer for today, but it is not a viable long-term solution. Media queries do not allow for reusable modules that adapt based on their containers’ size.
Responsive Web design is not limited to a set of technologies; rather, it is a different approach to designing and building websites. I, like many, took Ethan’s words about responsive Web design too literally and overlooked the essence of what was being said:
“Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design, but it also requires a different way of thinking.”
We have accomplished great things while embracing the stated “technical ingredients” for responsive Web design, but we have much room for growth when it comes to a “different way of thinking.” Thinking differently should affect not only how we design and build our websites, but also how we design and build the tools and technologies that our websites are founded on.
When I learned about how media queries could be used in responsive Web design, I was excited by the possibilities. However, it was not long before I learned of the limitations. Media queries are great for adapting layouts to various screen sizes, but terrible for creating modular designs. Modular CSS is already hard enough, and media queries provide very little to no help. Truly modular layouts need to respond to the sizes of containers, not just to the viewport’s size. Media queries, however, are based on the viewport, rather than an element’s container. There is some hope for standard CSS on the horizon, in the form of a W3C working draft, by allowing the cascade inheritance to be broken and resetting an element to its defaults. But what about media queries?
Web developers are masters at taking something created for one purpose and using it to accomplish other things. The Web’s history is littered with examples of this, and media queries are no exception. Kudos to Ian Storm Taylor for writing down his thoughts in the article “Media Queries Are a Hack.” Hacks are necessary on the Web to provide desired functionality until proper support is achieved, as well as to provide support to older browsers. The W3C states, “By using media queries, presentations can be tailored to a specific range of output devices without changing the content itself.” The key word here is “can,” but just because you can do something, doesn’t mean you should… But do we have any other choice?
Introducing the element query. An element query is similar to a media query in that, if a condition is met, some CSS will be applied. Element query conditions (such as min-width, max-width, min-height and max-height) are based on elements, instead of the browser. Unfortunately, CSS doesn’t yet support element queries, but that shouldn’t stop us from dreaming, hacking and pushing for new standards.
Consider the following example, in which the navigation menu should become visible when it reaches a minimum width of 500 pixels (representing one of many potential syntaxes):
nav (min-width: 500px) {
display: block;
}
Compare this to a media query in which the navigation menu’s visibility depends on the viewport’s width and needs to account for the padding and other declarations of parent elements:
@media all and (min-width: 520px) {
nav {
display: block;
}
}
Now imagine having to build a modular component that needs to be placed in containers of various sizes on a single page. One current approach is to provide different theme classes (like .module--large) to trigger CSS in media queries. This, however, adds a lot of complications and requires a module to know how its parent will react to various viewport widths.
There are several cases in which the CSS of an element query would invalidate the element query itself or create recursion. Hopefully, the browser would be able to detect these conditions and respond appropriately.
Consider the following examples.
Once an element reaches 500 pixels wide, it’s resized to 200 pixels, at which point the rule would no longer apply:
.element (min-width: 500px) {
width: 200px;
}
Once an element’s width reaches 31.250 ems, its font size would be decreased, which changes the definition of the em unit:
.element (min-width: 31.250em) {
font-size: 0.75em;
}
Once a container’s width reaches 450 pixels, the size of its child changes to 400 pixels, which would shrink the size of the container:
.container { float: left; }
.child { width: 500px; }
.container (min-width: 450px) > .child {
width: 400px;
}
There are many other such examples, but you get the point: Element queries are not as simple as we had hoped.
Element queries seem pretty awesome, but they also have some real issues. To help sort these out, I’ve written a proof-of-concept polyfill. The polyfill has enabled me to understand how a browser might react to various conditions. As I got further along, I realized that the polyfill could hold real value in the Web community’s debate on element queries, and that some developers could even start using element queries today.
The elementQuery polyfill script is available on GitHub for you to use, fork and contribute to.
The syntax used in the previous examples caused limitations, so I updated the polyfill to support an attribute selector syntax. The ~= attribute selector checks whether the value is contained in a space-delimited list (supported in modern browsers above Internet Explorer 6).
The following examples show CSS rules using the syntax required for the elementQuery polyfill.
This rule queries itself for a single condition:
header[min-width~="500px"] {
background-color: #eee;
}
This rule queries itself for multiple conditions:
header[min-width~="500px"][max-width~="800px"] {
background-color: #eee;
}
This rule queries a parent for a condition:
header[min-width~="31.250em"] nav {
clear: both;
}
Unfortunately, the elementQuery polyfill requires JavaScript and the Sizzle selector engine (which is embedded in jQuery). When the document object model (DOM) is ready, elementQuery scans the document.styleSheets collection for any CSS rules that use elementQuery. When it finds a match, it extracts the following information:
header, ul > li.class
min-width, max-width, min-height, max-height
500px, 31.250em
elementQuery then uses this information to add or remove attributes from elements that match the given selector and query condition.
Most browsers, but not Internet Explorer, don’t provide access to the contents of cross-domain style sheets, which causes issues when CSS files are served from a content delivery network. Additionally, parsing style sheets takes time (not much, though). So, I created two branches for elementQuery: master and prod. The master branch includes the code for extracting the necessary elementQuery information (selector, query type, query value), and it also provides a selectors() function to export the information. The prod branch requires the information to be declared in JavaScript, which avoids the cross-domain file issue and the time required to parse the style sheets.
Here is an example of how to export elementQuery information using the master branch:
console.log(JSON.stringify(elementQuery.selectors()));
And here is an example of how to import elementQuery information using the prod branch:
elementQuery({"header":{"min-width":["500px","31.250em"],"max-width":["800px"]}});
I’ve put together a few working examples on CodePen (using the master branch) that you can experiment with or fork. I would love to see what other examples people create (which will probably be much cooler than mine). Just be sure to tag them with #elementquery so that others can benefit.
I didn’t write this just to get you to jump on the element query bandwagon, but rather to encourage people to think about how we can solve the problems that are limiting our medium. Let’s keep the discussion going and make the Web a better place. So, go wild and make cool stuff!
(Source of image on front page: Looking Beyond Common Media Query Breakpoints)
(al) (ea)
© Tyson Matanich for Smashing Magazine, 2013.
]]>Researchers say that over a third of iPhone apps still access a device’s unique identifier.
In 2011, Apple advised that iPhone and iPad apps should stop logging the unique identifiers of users’ devices, a practice that can be exploited to build up profiles for ad-targeting purposes. But a new study by researchers at the University of California, San Diego, suggests that many apps still do so.
]]>