Why Native CSS Variables Will Be A Good Addition - Vanseo Design

---

Why Native CSS Variables Will Be A Good Addition Posted: 30 Jan 2014 05:30 AM PST On Monday I walked through css custom properties for cascading variables and mentioned that some people have objections to variables becoming part of the css language. Two notable objectors are Jeremy Keith and Chris Coyier. Note: This post includes an audio version. If you don’t see the audio above, Click here to listen. Before the holidays both made arguments against adding variables directly to css. I’d like to cover their objects and then talk about why I disagree and think css variables will be a good addition to the language. The arguments come down to 2 things. First is to question whether variables are necessary in css given that we have variables in css preprocessors. The idea being that we shouldn’t automatically add this abstraction layer, just because it enables us to abstract our code more. The second is that they would make css more difficult for beginners to learn. Here are Jeremy’s and Chris’ articles. They’ll do a better job explaining their objections than I ever will. Sasstraction About Variables in CSS and Abstractions in Web Languages Are CSS Variables Needed? In some respects I have a hard time understanding how this could be a question. If they aren’t necessary in css then by the same logic once variables were part of Less they weren’t necessary in Sass. However I don’t think that’s what Jeremy or Chris is really saying. While it’s true that variables exist in preprocessors there’s at least one thing they can’t do in a preprocessor that they would be able to do natively in css and that’s interact with Javascript. Javascript never sees preprocessed variables. It only sees the resulting processed output. I think being able to read and directly manipulate variables opens up interesting use cases. This alone makes it worthwhile to add variables to css. CSS is Easy to Learn The main argument though, is that adding variables to css will make the language more difficult to learn. One major benefit of css is how easy it is for people to pick up and get started. This ease of entry is part of the beauty of the language. CSS syntax is simple. 1 2 selector {property: value;} h1 {font-size: 2.5em;} It doesn’t take long to understand what’s happening in the code above or to write similar code on your own. Combine the basic syntax with how to connect css with html and you’re good to go. Variables in css will make programming languages more approachable and not make css less approachable CSS is also very modular as none of the pieces above rely on anything else in the stylesheet. It’s all right there in place. Adding variables would break this modularity as the values of the variables would be located in one place and the code to style a selector in another. Both Jeremy and Chris acknowledge that css animations already break this modularity as they require separate blocks of code for declaring and invoking the animation. Both think it’s probably the only way to make animations work. I’d say the precedent has been set. Do read both of their articles as I’m sure I’m not doing justice to their arguments. I think their point is ultimately that adding variables turns css into something more of a programming language than a markup language and that’s more difficult for people to learn and use. CSS Will Still be Easy to Learn Not too long ago I was reading Dan Cederholm’s new book Using Sass. Aside from it being a good book, I’m mentioning it here because Dan points out how easy Sass is to learn, especially if you’re using the .scss syntax. That syntax is the same as css so you can write your first .scss document the same way you would write any css document. Just change the file extension from .css to .scss and add some css code to the file and you’re officially writing Sass. It doesn’t get much easier than that. From there you can take advantage of the features of Sass one at a time. You can start by nesting your code. Your next step will probably be to work with variables. When you’re ready you can make use of mixins, extensions, and partials. You don’t have to use these or any other features until you’re ready. The point being it’s very easy to get started with Sass. If you tried to start with the more advanced features it would probably be confusing, but you don’t have to start with them. You never even have to use them to make Sass useful. Nesting and variables alone make Sass worthwhile. CSS can work the same way even if you add variables and other programming logic to the language. They wouldn’t be necessary for working with css, but they’d be there if and when you wanted them to be there. You’d still start by learning the basic selector {property: value} syntax and how you connect css to html. Once you understand both you understand how css works. You’re hardly an expert at this point. Your next steps with the language will likely be memorizing properties and values until you realize you don’t need to memorize either and instead find resources to look them up. Then you might work to better understand all the different selectors available to you, starting with ids and classes before moving on to attribute selectors, combinators, and pseudo selectors. At some point you’ll want to understand why one selector takes a property another can’t. You’ll seek to understand default values. Somewhere along the way specificity and cascading rules become important to learn. And then there’s how things work in combination to build layouts. What are the pros and cons to each layout approach? Should you use floats or positioned elements? What are these css table things? Eventually you’ll become interested in how your css files and the code in them are organized. Are you writing efficient code? Is your style consistent? Can others quickly understand what you’ve done and maintain your code? Yes, the very basics of css are easy to learn and understand, which makes the language approachable, but let’s not kid ourselves into thinking it’s all easy. There’s a lot to know about css. It’s an easy language for beginners to learn because you don’t need to know advanced topics of the language to use it. If you understand how to get an html file to read css and understand the basic syntax you’re good to go. How does adding variables to the mix change that? They’d just be one more to thing to learn when you’re ready. I’ll go further and suggest adding loops and conditionals and other features of programming languages would be no different. They’d be there when you need or want them, but wouldn’t be required to use the language. I’d be happy to see anything in preprocessors added directly to css itself. As long as these more advanced concepts aren’t requirements to working with css, the language will continue to be approachable and easy to learn. Why Programming Languages are Harder to Learn Programming languages are more difficult to learn not because they include more advanced topics, but because the basics are difficult the first time you encounter them. Installing the language is enough to scare off some people. True programming languages have steeper learning curves. The learning curve can be as steep as you want further down the line. The beginning is what makes a language approachable or not. Variables are typically among the first topics discussed in any programming language suggesting they’re one of the easier things to understand about programming. We all learned how variables work early on in school when we took algebra and started substituting x, y, and z for real numbers. If anything, I think adding variables to css will only make programming languages more approachable and not make css less approachable. Learning css would be the shallow part of the curve to learning the more advanced language. Summary Variables are coming to css. We won’t be using them tomorrow, but we will be sometime over the next few years. A few years ago that would have made designers and developers very happy. Today some people have objections to variables being native to css. I understand the objections. We already have the ability to work with variables and variables are more complicated than the basic css syntax. They probably aren’t the first things people new to the language should learn. So what. Nearly everything we do with css in real projects is more complicated than the basic syntax. Adding a more advanced feature to the language doesn’t make the basic language any more difficult to learn. If anything it’ll make programming languages easier to learn as css will shallow out their curve. There are also some use cases for having variables directly in css mainly because it would allow Javascript to read and write to those variables. Javascript can’t read and write to preprocessed variables. It only reads the post-processed css. What do you think? Are variables in preprocessors enough? Will variables in css make css more difficult to learn? You know where I stand. What about you? Download a free sample from my book Design Fundamentals. The post Why Native CSS Variables Will Be A Good Addition appeared first on Vanseo Design. This posting includes an audio/video/photo media file: Download Now

You are subscribed to email updates from Vanseo Design To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

CSS Variables — How To Use Custom Properties For Cascading Variables - Vanseo Design

---

CSS Variables — How To Use Custom Properties For Cascading Variables Posted: 27 Jan 2014 05:30 AM PST A few years ago one of the more requested features in css was the ability to create variables. With so many repeated values across a stylesheet, the abstraction makes a lot of sense. Then along came preprocessors like Sass and Less and we had variables. The talk for wanting them directly in css quieted down. The quiet hasn’t stopped variables from coming to css, though. Yes, variables are coming. Not quite yet, but they’re coming. Firefox nightly is currently the only browser to offer support, but variables are on the way. You’d think designers and developers would celebrate, but not everyone is happy about the news. Today I thought I’d run through how to use css variables as currently written in the spec. On Thursday I’ll talk about the objections some have to native css variables and why I disagree with those objections. CSS Custom Properties First things first. If you want to try any of this you need to grab a copy of Firefox Nightly. As I’m writing, it’s the only browser offering support. Again css variables aren’t anything we’re going to be using in production any time soon. The css custom properties for cascading variables module is currently in the working draft stage. I believe the next stage is candidate recommendation. Normally I’d wait until we’re closer to being production ready, but I was taking a deeper look anyway and thought why not share. Just keep in mind it’s early and a lot can still change. While I don’t expect it, for all I know everything below will be completely different by the time we’re using css variables in practice. In Sass variables are declared with a $ as in $variable. In Less the @ sign is used as in @variable. To reference the variable in either language you use it in place of a value as in color: $color or color: @color. CSS variables are a little bit more complicated, but not too much. In css they’re more than variables. They’re custom properties for cascading variables. To declare a custom property give it a name that begins with var- followed by anything you want. var-color var-background-color var-font-size and so on The spec defines a custom property as var-*: <any-value> and that <any-value> can get interesting as we’ll see further down. When declaring a custom property you’ll typically declare it on the :root selector. 1 2 3 :root { var-headline-color: #336; } To use the variable is also a bit different than it is for css preprocessors. 1 h1 { color: var(headline-color); } The code above would set the color of an h1 to #336. Like I said, a bit more complicated than how Sass and Less deal with variables, but not much. Let me try to clear up the custom property and variable thing. In the code above var-headline-color is the custom property. The variable name is headline-color, which gets referenced through the var(); notation. If that makes sense, great. If not, don’t worry too much about it. Something tells me everyone is going to refer to all of it as variables anyway. One thing to note is that property names are case sensitive so var-color, var-Color, and var-COLOR are three different properties. The var must be lowercase so VAR-color is invalid. You might be wondering why not just use $ or @, which are both easier to read. One reason is the notation above is more css-like. If you’re interested there are additional reasons which you can read about below. W3C Hammers Out the Details of CSS Variables CSS Variables, why we drop the $foo notation Let’s Talk about CSS Variables Cascading Variables You might have noticed the title of the spec mentions cascading variables. Above I set the variable on the :root element, which is what we’ll likely do much of the time. It means descendants of the root can access the variable. You can declare variables on more specific selectors instead. 1 2 3 :root { var-color: #000; } div { var-color: #333; } .box { var-color: #777; } The first variable above would be available to every element. The second only to divs and their descendants. The last only to elements with a class of box and their descendants. The usual cascade and specificity rules determine which variable is used on a given selector. For example if we have a div with a class of box in our html and in our css we set 1 div.box { color: var(color); } the resulting color would be #777. If you’re unsure why, I’ll refer to you my post on css specificity and cascading rules. Variables and Javascript One interesting example shown in the spec involves setting <any-value> to something other than a simple value like a color or a unit of measurement. 1 var-foo: if(x &gt; 5) this.width = 10; Not the most useful variable as the spec points out. It’s invalid as an actual value on any css property. However, it is something Javascript could read and act on. It also seems to indicate conditional logic might enter into css variables. Composite Variables Composite variables can be created by using other variables in the declaration. 1 2 3 4 :root { var-main-color: #c06; var-accent-background: linear-gradient(to top, var(main-color), white); } Here accent-background will always be a gradient from main-color to white. The value of accent-background would change as main-color changes. Fallbacks CSS variables can have fallbacks if the variable hasn’t been validly declared or declared at all. 1 2 3 .header { color: var(header-color, blue); } If var-header-color has been validly declared, it’s value will be used as the color for .header. If not, blue will be used. An Example Since I have my code editor open as well a Firefox Nightly installed and open, I thought I’d share a not so exciting example. As this only works in Firefox Nightly, I’ll present screenshots for what’s going on. First I set up some simple html 1 2 3 4 5 6 7 8 9 <body> <p>Body</p> <div class="container"> <p>Container</p> <div class="box"> <p>Box</p> </div> </div> </body> Just one div inside another inside the body. Each div has a paragraph inside with some text to identify it. Next some default css to present everything 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 html { font-family: georgia; font-size: 16px; } body { margin: 0; padding: 0; } .container, .box { max-width: 75%; margin: 0 auto; height: 100vh; } p { float: left; margin: 1em; } At this point all we have is three words on a white background, which isn’t particularly exciting. Let’s add a custom property and then use the variable. 1 2 3 4 :root { var-background-color: #393; } body { background: var(background-color); } Assuming custom properties work we should see the same 3 words only this time on a green background, which is exactly what we see in Firefox Nightly. Still not all that exciting, other than to prove that variables work. Let’s add another custom property, this time on the .container div and then use it to set another background color. I’m placing them together, but more likely you’d set the custom property in one location and use the variable in another. 1 2 3 4 .container { var-background-color: #339; background: var(background-color); } You can see the background behind the body is still green and now the background behind the container is blue. Even though property and variable have the same name for both the body and the container div, each element knows which value to use and it’s based on the rules of the cascade. Let’s call the variable on the .box div without setting up a new custom property for it. What color background do you expect the .box div to have? 1 2 3 .box { background: var(background-color); } It’s inside .container so it inherits the custom property set on .container and use the same blue background. The screenshot is the same as the one directly above so I won’t show it again. What if we switch the name of the variable on .container? 1 2 3 4 .container { var-container-background: #339; background: var(container-background); } The backgrounds on the body and .container remain the same, but now .box inherits from the body and gets a green background. Let’s change the .container div one more time and set the custom property back to background-color, but call the variable container-background. Let’s also provide a fallback when we call the variable. 1 2 3 4 .container { var-background-color: #339; background: var(container-background, #933); } Now .container is trying to use an invalid variable so it gets a reddish fallback color (#933). The .box div inherits the custom property set on .container though, and shows a blue background instead of the green that’s on the body. One last example. This time we’ll build up the custom property on the .container div using the var-background-color property set on the :root. 1 2 3 4 .container { var-container-background: -moz-linear-gradient(to top, var(background-color), #933); background: var(container-background, #933); } Because .container is a descendent of :root it can inherit the background-color variable. We use the variable as one of the values inside a linear gradient, which gets set as a the value of a new custom property. The .box div is still set to use background-color, which it inherits from :root and the result is the following. Again this is a rather simple example, but hopefully it illustrates some of the things you can do with custom properties and variables in css. If you’d like to see more information and examples you can check the links below. Playing around with CSS variables – “custom properties” Using CSS variables New Awesomeness: CSS Variables CSS Variables in Firefox Nightly Closing Thoughts Just as we’re getting used to variables in preprocessors, Firefox Nightly has gone and supported css variables. Native css variables are a little more complicated in their syntax, but hardly much and the slight bit of complication makes them more flexible than their preprocessor cousins. It’ll be awhile before anyone is using css custom properties in production, but you can certainly give them a try today. They’re very easy to work with. At the start of this post I said not everyone is happy that variables are coming to css. Both Jeremy Keith and Chris Coyier have posted they don’t think css variables are necessary given we have them in preprocessors and both think adding variables will make css a less approachable language for beginners. I strongly disagree, but we’ll get to that on Thursday. Download a free sample from my book Design Fundamentals. The post CSS Variables — How To Use Custom Properties For Cascading Variables appeared first on Vanseo Design.

You are subscribed to email updates from Vanseo Design To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

Designing Unknown Content In 2 Dimensions - Vanseo Design

---

Designing Unknown Content In 2 Dimensions Posted: 23 Jan 2014 05:30 AM PST Earlier in the week I was talking about relative measurements like root em (rem) and the different viewport measurements (vw, vh, vmin, vmax). It reminded me of some things I’ve been thinking about in regards to designing for unknown content and some of the differences in designing for print and the web. Note: This post includes an audio version. If you don’t see the audio above, Click here to listen. I’m not trying to lead you to a specific conclusion with this post. It’s mainly me thinking out loud, sharing some observations, and raising a few questions. Designing Templates I hope you agree that having the final content before you design is best. Unfortunately we don’t always have that luxury and we often have to design without specific content. I don’t mean the times when the client hasn’t given you the exact content yet, but rather the times where the content doesn’t exist yet. Think anything beyond a brochure site where content creation will be ongoing. An easy example is a blog. We can’t have all the content in advance because no one knows what that content will be. Sometime in July I’ll publish a post, though at this moment I have absolutely no idea how long that post will be, whether it will contain images, or code, or anything else. It’s unknown. What we often design is less a page than a template meant to be home for a known type of content within certain constraints. Maybe the design can only accommodate some maximum columns of images. Designing Fixed vs. Flexible We design in a 2-dimensional plane. We have a vertical and horizontal direction. We don’t always know how much content will need to be presented or how big or small the viewport will be when it’s viewed. This leads to a challenge in allowing our templates to grow and contract, at least in one of the 2 directions. Print doesn’t share this issue. The canvas is fixed in both directions. The content changes to fit the canvas. Magazines have strict word counts for articles because the article has to fit within a predetermined space. We don’t have that luxury online. The content will change and our design has to change with it. Blog posts don’t have word counts. A post can be a single sentence or it might be 10,000 words. We could design several templates, say a short, medium, and long template. We could design templates for different posts types. Most content management systems do this already. If you remember last last summer I was exploring some of the coming css layout modules like regions and grids. With each you set both width and height for the techniques to be effective. In other words both modules will work best when the content is known or changes infrequently. When content is unknown as it is much of the time, we can’t set dimensions in both directions. We need to allow for the flexibility of the unknown content. Why We Fix Widths and let Heights Grow Dynamically We can still fix one of the two dimensions as long as we allow the other to dynamically change size. By fix I don’t literally mean we have to use absolute measurements like 960px. I mean fixed in the sense that the size doesn’t overflow the visible viewport. We can still use relative measurements. If we fix one dimension, we have to allow the other to grow and contract to any size it needs to be to house the content that eventually gets places inside. It’s far more common to fix widths in this way and allow the height of the design to extend beyond the visible viewport. I think this is mainly because a mouse makes it easier to scroll vertically. Horizontal scrolling usually means clicking and dragging the scroll bar left and right, which isn’t the easiest thing to do. CSS might be another reason in that width: 100% works much better than height: 100% much of the time. Perhaps the latter is one good reason for using vh. For both of these reasons vertical scrolling has become the convention. Touch Input Changes Expectation and Capability Touch devices change this. On touch devices it’s just as easy to scroll horizontally as it is vertically. The mechanism is in place for people to move the content any which way they want. Over the years I’ve seen designers experiment with horizontally scrolling sites. They often look great, but at least when used with a mouse on a desktop or laptop they haven’t been as usable as their vertically scrolling counterparts. The rise of touch enabled devices is changing this and perhaps changing our expectations of how a web page should scroll. I see more and more designers experimenting with scrolling in directions other than vertical, some probably just to be different, but more to accommodate touch devices. For the most part you’d still have to ensure content fits within the height of the viewport, which again isn’t always easy without something like vh. A New Type of Narrative In theory you could leave both dimensions open and dynamic where touch devices are concerned, but it becomes more difficult to create a narrative flow, which typically moves in a single direction. If you allow visitors to move wherever they want you have less control over the direction they move through your content. You could still guide their movement through your design, but some control would be gone. Then again haven’t we learned over the last few years that any control we think we have is really illusion. Perhaps we have no real choice and before long we’ll have to accept a certain loss of designing a certain flow. Perhaps we’ll have to look for others ways to direct the flow or even seek a different kind of narrative. In allowing visitors to move where they want, perhaps we should encourage more exploration and less guided tour. We might still serve as guide by fixing site navigation. Imagine a website where all the content is on a single page. Instead of taking you to a new page, menu items move the page around and position what you want inside the visible viewport. It shouldn’t be too hard to imagine. Plenty of single page sites do this now and we’re already using off canvas patterns in responsive designs. I’m not saying these are the best ideas. There are probably other ways to navigate around, but leaving everything open and moving the page itself around is certainly more possible. I’d say it’s probably a good time to rethink how we move around web pages and websites. Closing Thoughts I think it’s safe to say fewer people use a mouse today than a few years ago. I can’t remember the last time I used one, though it was probably a 10 or 12 years ago when I last held an office job and was working on a desktop. Tablets, phones, and even laptops are bringing touch inputs to more people where our ability to scroll in any direction isn’t constrained by the input device. At the same time, I think enough people still use a mouse and see vertical scrolling as the convention where this should still be the primary direction of scrolling in the near future. Still, it’s probably a good time to start experimenting more and try leaving the horizontal as the open direction to grow with your content or even leaving both directions open to expand and contract as desired. It’s probably also a good time to rethink how we navigate around a web page or website. Download a free sample from my book Design Fundamentals. The post Designing Unknown Content In 2 Dimensions appeared first on Vanseo Design. This posting includes an audio/video/photo media file: Download Now

You are subscribed to email updates from Vanseo Design To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

Design Fundamentals: Download Your Free Sample From The Book - Vanseo Design

---

Design Fundamentals: Download Your Free Sample From The Book Posted: 21 Jan 2014 05:30 AM PST When I released my book Design Fundamentals a few months back, quite a few of you suggested I should offer a free sample. It was a good idea and a complete oversight on my part for not having offered one initially. I’m correcting that today. I thought about offering the introduction to the book as the sample, but decided instead to offer something meatier from deeper in the book. I figured this would give you a better feel for what’s in the rest of the book than the intro would. I opted for the section about direction and movement. It’s from the chapter of the book that discusses different attributes you can apply to design elements. It’s also a topic I haven’t specifically covered before here on the blog so hopefully it’ll be something new for you. You can download your free sample here. Of course, I won’t object if you decide instead to just a buy a copy of the book. Thanks. Download a free sample from my book Design Fundamentals. The post Design Fundamentals: Download Your Free Sample From The Book appeared first on Vanseo Design. This posting includes an audio/video/photo media file: Download Now

You are subscribed to email updates from Vanseo Design To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

REMs And Viewport Measurements — Why You Shouldn’t Use Them Yet - Vanseo Design

---

REMs And Viewport Measurements — Why You Shouldn’t Use Them Yet Posted: 20 Jan 2014 05:30 AM PST Designing for the web means designing flexibly. It means dropping absolute measurements and adopting relative ones like em and %. There will be exceptions, but for most things you should be using relative measurements. Ever since I started designing responsively, I’ve been working with % for horizontal measurements and ems for vertical measurements. I rarely use px any more. You’d think I’d also use relative units of measurement like rem, vw, vh, vmin, and vmax, but to this point I haven’t used them in any way. While they appear useful, each has given me some pause and reservation that’s kept me from using them in practice. I’d like the share those reservations along with what each of these measurements does in case you’re unfamiliar with them. Root em (rem) You don’t have to work with em units long before encountering a couple of difficulties. First is the math. 12px (target) / 14px (context) = 0.857142857em (result) Not exactly the nicest looking result. I’ve come across this particular string of numbers so frequently it’s now committed to memory. It’s common to deal with long strings of numbers like this when working with em units. I prefer numbers like 1.5, 1.8, and 2.4. Before you opt for rems and viewport measurements think about what’s gained and lost with each The other difficulty is that it’s easy to lose the context when you nest elements. The heading in the main content needs a different value than the same level heading in the sidebar and both are relative to different containers with different em values. It leaves you overriding more values than you want and it’s easy to get confused. The root em (rem) unit solves both problems. Instead of being relative to the parent, the rem is relative to a single root. There’s no getting lost in the context, because the context is always the same. It’s always the font-size of the root element, which is the html tag. How easy the math is or isn’t depends on the root value, which by default is the equivalent of 16px. Dividing by 16 is not messy or difficult. It’s the kind of math you can do in your head after a little of practice. If division by 16 sounds scary, you can use the trick of setting the font-size of your html element to 62.5% (10px). I hope everyone agrees that division by 10 is simple and undeserving of sympathy. 1 2 3 html font-size: 62.5% // =10px .sidebar font-size: 1.4rem // =14px h2 font-size: 1.8rem // =18px Browser support is very good. Only IE8 and below and Opera Mini don’t support rem units. It’s possible you may not need to support either for a project. Given how easy the above is why do I have objections? My reservations are in the fallbacks for IE8 and Opera mini and the reason for using rems in the first place. We use rems because they’re easier for us to work with. They don’t offer any specific advantage over ems other than being easier for us to work with. Now consider the fallbacks. For browsers that don’t support rems you need to fallback to another unit of measurement. One fallback option is ems, but if you have to calculate ems it defeats the whole point of using rems in the first place. The other option is to fallback to px, which is what most people will do. Typically you’d set up a mixin in Sass or Less. Easy enough, but it means we’re falling back to absolute measurements, which I’d also argue defeats the point. I’m all for rems and prefer to use them over ems, however, let’s remember they exist solely to make our lives easier. Nothing is gained from them except saving some math and helping us not get lost in the context. Both are valuable things to gain, but are they more important than what you might be giving up? The answer depends on the specifics of your project. One other issue is that rems don’t quite work as you’d expect in media queries, which you can see in this demo. It’s easy enough to set media queries using ems, though. It still means the possibility of some not so tidy looking values, but it doesn’t come with the nesting issue. So while this is something to take into consideration, I don’t think it’s that big of a deal. Once Opera Mini offers support and once IE8 falls completely out of use I’ll be using rems regularly. When I have projects where neither needs to be supported I’ll be using them as well. They are certainly easier to work with. However, until then I’ll suck it up and do the math required to use ems most of the time. Sure it can be confusing, but it’s not exactly difficult. Viewport Measurements Where rems size elements relative to the root size, viewport measurements size elements relative to…you guessed it, the viewport. Seems like something useful don’t you think? Let’s take a look at the measurements. 1vw = 1% of viewport width 1vh = 1% of viewport height 1vmin = 1vw or 1vh, whichever is smallest 1vmax = 1vw or 1vh, whichever is largest At first you might wonder what’s the big deal with something like vw as it looks like another way of setting an element as a % of the whole, but keep in mind with vw the context is always the viewport and not the parent element. When you nest elements, % can get messy the same way ems get messy. It’s easy to get lost and forget the context a few levels deep. With vw the context is always the same, the viewport. Browser support is similar to the support for rems. It’s not quite as good, but it’s close. IE9, IE10, Blackberry and IE Mobile have partial support in that they don’t support vmin and vmax. Opera Mini and IE8 offer no support at all. Once again we have to deal with the same fallbacks of using another measurement. If we select something relative like %, we might as well just use % everywhere. If we select something absolute like px, we have to ask if we’re gaining enough to give up relative measurements in some browsers. I think there are bigger issues, though. Some have suggested using viewport measurements to size text. This is an awful idea for most text, which shouldn’t be sized based on the size of the canvas, but rather your distance to it. I don’t want the text on my phone to be 20% the size of that same text on my laptop (roughly the difference in viewports) It can be a little smaller because my phone is usually closer to my eyes when reading, though not that much. Speaking of the canvas, I thought a big part of this responsive revolution was understanding that we should be designing content out and not canvas in. I do think there are some interesting use cases, though. For example you might want the size of an element to be 100% the height of the viewport. It’s not something I typically want, but some do and it’s not that easy to do with css. Using vh it becomes quite simple. Despite it not being a good idea for text in general, viewport measurements are useful for some pieces of text. Say a heading which you want to always span a certain amount of the viewport. That text likely remains large enough to read regardless of device. Light boxes are another good example where size relative to the viewport is a good idea. I’ll stick to other relative measurements for now. Even when browser support is 100%, I’ll probably only use viewport measurements sparingly and for particular use cases. I do think they’ll be very useful for some things, but not everything. Summary If you’re not yet using relative measurements, you should be. We don’t design for an absolutely sized canvas and so using absolute measurements doesn’t make sense. Two types of relative measurements you may be tempted to use are root em and the various viewport measurements. Before you do, think about what is gained and lost using each. I’m excited to use rems, though not until browser support is complete. The fallbacks don’t make any sense to me. They defeat the point of either an easier calculation or using relative measurements. I have similar reservations about viewport measurements and wonder if we should be sizing anything relative the canvas beyond a few small cases. I expect rems to eventually become the standard unit for sizing text and vertical measurements in general. I’m not so sure about vw, vy, vmin, and vmax. Some will see them as standard units, but I don’t think it’ll be the case for the industry as a whole. Rather I think they’ll be very useful for some use cases, but not all. Do you currently use rems? How about the viewport measurements? If so, how do you find them in practice? If not, do you share my reservations or do you have some of your own? Download a free sample from my book Design Fundamentals. The post REMs And Viewport Measurements — Why You Shouldn’t Use Them Yet appeared first on Vanseo Design.

You are subscribed to email updates from Vanseo Design To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

iCan't Internet

---

Paying heed to link placement during HTML to WordPress conversion Posted: 20 Jan 2014 07:29 AM PST The user-friendly features of WordPress CMS have made it one of the finest CMS tools used by a wide majority of web developers residing in different corners of the world. It's been believed that a... [[ This is a content summary only. Visit my website for full links, other content, and more! ]]

You are subscribed to email updates from iCan't Internet To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

How Design Patterns And Component Libraries Create Unity And Context - Vanseo Design

---

How Design Patterns And Component Libraries Create Unity And Context Posted: 16 Jan 2014 05:30 AM PST Earlier in the week I offered some thoughts about components, design patterns, and pattern libraries. In that post I shared some things about the house I grew up in and how it was built on the same plan as other houses in the neighborhood. I want to talk a little more about the neighborhood and how it created a context for each of the houses within. Note: This post includes an audio version. If you don’t see the audio above, Click here to listen. A few years ago my brother passed by our old house. He noticed how much the owners had changed it and the next time I was in town we both drove by to have a look. The owners had customized the house a lot. The changes certainly gave the house a unique look within the neighborhood. It wasn’t a complete rebuilding from scratch, but it might as well have been. They added a second story, gave it a very different paint job than most of the other houses, and redid the landscape of the front yard. If I showed you a picture of the house when I lived in it and one after the changes, you probably wouldn’t recognize it as the same house, unless you could also see the houses on either side. Because of the changes the house stood out, though not in a good way. It stood out in more of a sore thumb kind of way. It wasn’t that the house looked bad, but it no longer fit in the neighborhood. Move it somewhere else and it might look great, but not in that neighborhood. It broke the expectation set by the context of the houses around it. It doesn’t fit in the neighborhood anymore because it veered so far away from the original plan. The plan might have led to some less than exciting homes, but it did create a consistent pattern and context. Creating a Unified Context Through Components Components and patterns help create unity. They help create a consistent context. It’s why Mac apps look different from Windows apps. Each is designed to work better within the context of a specific operating system. Each is designed to fit within its own neighborhood. It’s also why Apple and Microsoft create APIs and developer libraries. A large part is to help make it easy to develop for the platform, but those libraries also exist to help create a consistency across each operating system. Like the houses in my old neighborhood, component and pattern libraries might lead to more of the same interfaces, but they also lead to increased usability. In the case of a living in a house that increase might not be a big deal. You have plenty of time to learn your way around your house. It’s something to keep in mind though, when designing and developing websites. I’m guessing most sites you create have some buttons. Maybe not all, but buttons are likely a very common element on the websites you design and build. Odds are you don’t create a new button from scratch every time you need one. You probably design a single style and apply it to a button element or maybe to a button class that you apply to a link. When you need a second button you add a new button element or add that same class to another link. If a button needs to be a little different, for example blue instead of a default red, you reuse your button styles and override the color. Even with a different color, the buttons retain mostly the same style so that each fits within the overall context of the site and buttons on the site. On a single site you might call this a style guide, but it’s also the beginning of a component or pattern library. From Style Guide to Component Library You can extend your button style beyond a single site. You’d need a greater variety of buttons if you’re going to use them on multiple sites and yet the buttons you create from site to site probably share a lot in common. Each has a shape. Each has a color. They include text inside as well as a border, even if that border is 0px wide. Each button should be clickable and change over the different states of a button. Maybe the color changes on hover and the size transforms when clicked. Perhaps your 0px border becomes 1px wide in one button state. You might even give your buttons a realistic appearance that makes them appear pressed in when being clicked. There are a lot of different ways to design and develop a button, but the truth is most of the time any button you design is going to share a lot of similarities with buttons you’ve designed before. I know it’s that way for me and those similarities come from my own design tastes and my own development practice for creating buttons. When choosing the color for a button I choose from my preferred color palette. If I round the corners there’s a minimum and maximum amount of roundness I’ll use. If something is going to transition over time I’ll use my judgement as to how quickly it should change over how long a time span. Every site is different. You wouldn’t design the same buttons for a bank and for a children’s site. Every client is also different and they’ll come with their own set of preferences. However, the first button I present will likely suit my tastes. My preferences form my design palette and they cover a large enough range of options that I can choose something from within the palette that works for the given project, but it’s still my palette that comes from my preferences, judgement, and experience. It’s my context as a designer. I think this is how a designer or developer creates his or her own style or voice. By choosing our palette and reusing our components we add our style to a project. Some might argue we shouldn’t be imposing our style on a client project, but I think it’s inevitable we’re going to do so. None of us has skills for an infinite number of possibilities. We choose constraints on projects and while most should come from the specifics of the project some will always come from us. Our style will find its way into a design whether consciously or subconsciously and given it’s going to happen anyway, I’d rather it be a conscious choice. By using component libraries that choice can be more consistent with other choices. It can be part of a larger consistent context. Components Don’t Have to be the Same What you save as a component for a button doesn’t require that every button will look the same on every site. For example any button you create likely includes shape, size, color, and type. Think about all the variety that can fall within and across those 4 items. There are probably millions of different combinations of shape, size, color, and type. You can create a component that includes all of the above, but allows their specific values to vary on each button or group of buttons. You can make different buttons unique while still using the same component to build them all. Components and pattern libraries can lead to greater similarity across elements. That can be a good thing at times in that it creates a unified context. Similarity doesn’t have to mean sameness though. There can still be more than enough variety to keep things unique. If you liked this post, consider buying my book Design Fundamentals The post How Design Patterns And Component Libraries Create Unity And Context appeared first on Vanseo Design. This posting includes an audio/video/photo media file: Download Now

You are subscribed to email updates from Vanseo Design To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

Components, Design Patterns, and Creative Solutions To Custom Problems - Vanseo Design

---

Components, Design Patterns, and Creative Solutions To Custom Problems Posted: 13 Jan 2014 05:30 AM PST I grew up in a house on suburban Long Island. The house was in the middle of a neighborhood where all the houses were built on the same plan. They were all built from the same design pattern. Our front door opened into a short entry way. On one side was the living room. At the end of the entry way on the other side was a longer hallway, with entries into 5 other rooms. Along one side you’d encounter kitchen, bathroom, and a bedroom. On the other side was a bedroom and the master bedroom. Every house in the neighborhood was essentially the same. The pattern was flipped at times. The living room in my house was to the right and in others it was to the left. Some homeowners customized things by adding an additional room. We had a den off the kitchen. A friend had an additional bedroom connected to one of the other bedrooms in the house. Would these homes have been better had each been unique? It’s hard to say. The sameness made things less interesting, however, building this way was clearly efficient and kept costs down allowing families to own homes. It certainly made it easy to know where the bathroom was when visiting friends. Better comes down to perspective. In this case what do you as the buyer consider more important in a home. Affording one or having a house custom built specifically and uniquely for you. I share this story of my upbringing because I want to talk about patterns and modularization, though in regards to web design and not the architecture of one suburb on Long Island. I also think this story fits well with the productivity and creativity conversation I often have here. The Good and Bad of Components and Pattern Libraries I’ve talked in the past about modularization and don’t want to rehash everything I’ve said before. You can view posts in the archive tagged modular if you’d like more than what’s here. Pattern libraries have existed for a long time, probably since shortly after someone discovered they were building the same thing again and again. When we work with components and patterns we work with larger and fewer blocks. There are still more than enough to form unique wholes. This past summer Brad Frost posted an article about atomic design in which he talked about developing design systems as a opposed to a collection of web pages. The post also announced Pattern Lab, which as you might guess is a collection of design patterns, in this case, classified under chemical names like atoms, molecules, organisms and so on. Much like the plan that housed my early years, pattern libraries are created to help develop more efficiently. The library builds reusable components, which are combined into ever larger patterns, which eventually become templates for web pages and websites. One designer who isn’t crazy about the idea is Mark Boulton. Mark is someone who’s work I admire greatly and so when he argues against designing this way I naturally listen and think deeper about the issue. Mark summed up his feeling about designing component up in this tweet. I’m not sure we can create great web experiences by designing the bits first and hoping they all come together and work beautifully. Mark shared more thoughts in his post, Design Abstraction Escalation. He argues we lose something when we design around components. We give up a sense of humanity in our work and replace it with a manufacturing process. We give up creativity in the name of productivity. Mark expects to see a sameness in design that I saw in a neighborhood many years ago if we follow this component path. However, he doesn’t necessarily have anything against collecting patterns. In fact he does that himself, but he never uses these patterns directly. The act of collecting them reminds him they exist and when he decides to use something similar on a new site he recreates it from memory, ensuring it ends up being unique. The library becomes inspiration, a starting point for recreating something unique, instead of as a machined part to be assembled. Punch Cards, Assembly Language, and Higher Level Programming Languages Computers speak in states. A circuit is open or closed, on or off. Everything is essentially a 0 or a 1. Computers speak a binary language. Human beings can speak it too, but not easily. In the early days of computing you communicated with the computer using punch cards. A spot on the card was either punched or it wasn’t representing one of two states. As you might expect it wasn’t particularly efficient. Punch a hole where you meant not to and you started again and who among us can look at a series of holes and non-holes and quickly understand what instructions are being given. Assembly language is a somewhat more efficient way of communicating with the computer, though it also involves a lot of 0s and 1s and it’s written specifically for one type of computer architecture. It’s also not that easy to work with. While it’s a language close to the way the computer speaks, it’s far away from how human beings speak. Our conversation with computers has evolved to be more in tune with how we communicate. Assembly gives way to higher order programming languages and humans are better able to write programs. It continues as we build reusable patterns we know work to handle low level details like memory management. Programmers can then move up the abstraction chain working to solve higher order problems while the lower level details are dealt with by the pattern. Nothing prevents you from recreating that pattern anew for a specific project should you desire, but not having to allows you to solve higher level problems. Patterns, Constraints, and Creativity It’s hard for me to disagree with Mark’s thoughts above. I prefer custom solutions to unique problems over cookie cutter solutions to lots of problems. I want creativity. I want interesting. I want the custom and unique. At the same time I understand not every problem is entirely unique or needs to be seen as unique. As I talked about last week, different clients have different needs and wants. They’re going to seek different solutions. Many can’t or won’t spend what’s necessary for the unique solution. Good enough is good enough and here patterns can help us keep costs down to serve a section of the market. I also don’t think all creativity is lost when we fall back on patterns. In fact I don’t think much, if any, has to be lost at all. Creativity and productivity aren’t as opposed as we sometimes think. Every website is a combination of components. Designers combine blocks to build something larger. Each block can be the same as others or it could be unique. They can be different shapes and size and color. Blocks that look the same can be developed in many different ways. Design is how we combine these same and different blocks into a whole. Many different wholes can be formed from even a few similar blocks. When we work with components and patterns we work with larger and fewer blocks. There are still more than enough blocks to form unique wholes. Larger and fewer blocks don’t negate creativity. They don’t prevent the creation of something custom or unique. There won’t be quite as many different combinations, but isn’t removing possibilities something we do all the time? Don’t we start a project by defining constraints in order to eliminate an infinite amount of possibilities, reducing them a manageable few? Working with fewer and larger blocks doesn’t mean we have to lose creativity and custom. Perhaps it increases the odds of sameness, but that’s just one more challenge we get to overcome. Grids are Patterns What are grids? They’re patterns of space. They reduce an infinite number of possibilities to a manageable few in the name of order, logic, and efficiency. They’ve also been accused of leading to a sameness in layout and design. A grid doesn’t suggest there’s only one location for an element, however. It allows for a variety of different locations for any element and provides far more combinations for the location of all elements. A grid is a constraint in the same way a component or pattern is a constraint. Nothing, of course, requires you to use a grid or even place every element on the grid should you use one. Nothing requires you to build from components and patterns or from using a particular component or pattern even if you do use them. Summary Components and patterns are a form of constraint. They combine small blocks into larger ones and reduce the number of blocks we play with. Fewer and larger blocks do reduce the total number of possibilities, but not to the point where we can’t still build creative, custom, and unique wholes. Yes, it increases the likelihood of sameness, but it doesn’t require it. Sameness is not always a bad thing either. Not every design needs to be custom. Sometimes good enough is all that’s required for the specific problem. In exchange for the ease and efficiency components and patterns give us, we take on the responsibility of knowing when sameness is ok and when a custom solution is preferred. Creativity and humanity are lost only if we allow them to be lost. Neither is dependent on what kind of blocks we play with. If you liked this post, consider buying my book Design Fundamentals The post Components, Design Patterns, and Creative Solutions To Custom Problems appeared first on Vanseo Design.

You are subscribed to email updates from Vanseo Design To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610