Freebie — Exclusive Vector Icon Set For SEO And Data Analytics - Vanseo Design

---

Freebie — Exclusive Vector Icon Set For SEO And Data Analytics Posted: 27 Feb 2015 05:30 AM PST Do you find yourself looking for free images you can use in projects? How about those times you need a vector graphic? If you answered yes, you might like the freebie I have for you. Shawn Rubel of Vecteezy contacted me with a free and exclusive set offer of 36 seo and data analytics vector icons only for readers of this site. Download Icons I usually don’t post freebies, but this one seemed like a good idea, since I started the year with a series about scalable vector graphics. If you enjoyed the series and are waiting for more, don’t worry. I’ll get back to the SVG series before long. I have plenty of topics left to cover. The Offer The exclusive is that these specific icons are available only here. You won’t find them on another site. You can see the icons in the images throughout this post. The zip file contains .ai, .eps, .png, and .psd files for each icon. You can download the zip here. The desaturated colors fit my color preference, but you can change the colors to whatever suits your needs or taste. It’s a nice set of icons for something related to marketing, analytics, seo, or data in general. Where to Find More There are a lot more free and premium graphics at the Vecoreezy site. To give you an idea how much, I did a search for free and the site returned more than 25,000 results. Odds are you can find something you’re looking for or close enough. One question I have with any site that offers images is what can I do with the files I download. Vectoreezy holds the copyright on their images, but you have the right to use or modify any of their downloadable items for use: in anything personal in websites as part of the design incorporated into merchandise for sale (t-shirts, mugs, posters, etc.) in prints for packaging (cd covers, gift wraps, etc.) – in advertising prints( posters, fliers, etc.) You can’t resell the images or set up a direct download to them. In general you can use the images however you like as long as you don’t redistribute them in any way, which seems fair to me. Enjoy. Download a free sample from my book Design Fundamentals. The post Freebie — Exclusive Vector Icon Set For SEO And Data Analytics 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., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States

Learning Is More Than Where You Get An Education - Vanseo Design

---

Learning Is More Than Where You Get An Education Posted: 26 Feb 2015 05:30 AM PST Is where you get an education or how you get an education important? I think it’s less important than many would think. It’s the education that’s important and not so much where or how you get it. Note: This post includes an audio version. If you don’t see the audio player above, Click here to listen. You can also subscribe in iTunes It doesn’t make a difference whether you learned to read in a classroom or from your parents or while watching Sesame Street. What matters is that you can read. A few years ago I wrote a post talking about education. It was in response to a couple of guest posts here that discussed the value of a earning a degree or learning on your own while you work and gain practical experience. In my post I talked about theoretical and practical knowledge. I tried to show the good and bad of learning theory in books and school as well as learning by doing the work to gain practical knowledge and experience on your own. I received a comment recently on that older post, though I didn’t approve it. At first it seemed like a legitimate disagreement with something I said and I started thinking what I would say in reply. As my thoughts continued, I began writing them all down and before I knew it I had more than enough notes for a post. The more I looked at the comment, the more it looked like a case of trolling and so I didn’t approve it. My apologies to the commenter for any error in interpretation I made, but trollish is how the comment ultimately came across to me. The Comment that Led to This Post I do have to share a little of the comment for this post to make sense. The gist was from something I’d said in the post, “;where you get your education isn’t important.” However, that fragment was taken out of context. It’s only half of what I said and the meaning is very different. When you put the fragments back together what I was saying throughout the post was that where you get your education isn’t as important as the quality of the education you receive. My point was (and still is) that you can get a quality education in a variety of places and no one place is automatically the best for everyone. I think if you read the whole post or even just a few paragraphs around the half sentence in question it’s clear what I meant, but maybe not. Maybe the comment was a real disagreement with what I had said, which means I failed to communicate what I wanted to say to at least one person and probably more. I thought I’d try again to make the point. I stand by my words in the previous post. It was sort of a follow-up to a couple of guest posts here debating the value of going to school and getting a degree or working four years and earning money. Ultimately I think it’s important to get an education, but where you get it is less important. By “;where” I don’t specifically mean what school you went to. I mean did you go to school at all or did you teach yourself by reading books? I mean did you learn by doing the actual work and gaining practical experience? Those are the kind of things I mean by “;where.” My Education Before I make the case again, let me start with my background and why I think I’m qualified to make a case at all. I’ve taken at least a semester’s worth of courses at five different schools over three different states. Three of the schools I attended for years and the schools vary in their perceived quality. I’ve been to one school that would probably be considered elite, another that’s seen as good to very good, and a third that I’d characterize as an average state college in a very good state university system. I’ve also taken a semester’s worth of courses at a community college on Long Island and I’ve taken a number of continuing education and undergraduate courses at the university here in Boulder. I attended all those courses over a span of 20 years. I wasn’t in school for 20 years in a row, but first class to last spans 20 years. The result is two undergraduate degrees, one in European History and one in Civil Engineering. In other words I’ve taken a wide variety of both math and science courses and liberal arts courses. You can toss in a couple of certificates in C++ and Web Design as well. Over the years I’ve also taught myself quite a bit. I taught myself in between some of the schools I attended and I’ve taught myself since the last time I was inside a classroom. Most anything you read here is something I’ve taught myself. Admittedly this is still a relatively small sample size of schools. Four of the five are from a small geographic area in the North East of the United Staes. There are certainly people who have received more education from more colleges and universities than I have, but I’m pretty sure I’ve had more formal education than most; not all, but probably most. I’ve taught myself more outside of school than I learned inside classrooms and it’s probably more than what most people teach themselves. I like to learn new things. I also think it makes me at least somewhat qualified to talk about the subject. Regardless of where or how I gained an education, I’ve found the quality always has more to do with me and my effort than with who’s delivering the education. I’ve worked hard and not so hard at both good and not so good schools and I’ve found what I took away from the experience in all cases is much more connected to my effort than what school I went to. I’ve also worked hard and not so hard at things I’ve tried to teach myself and again what I gained was directly a result of my effort, not my ability to learn or teach. You Learn So You Can Make Better Decisions In one sense life, like design, is a long series of decisions. We all make decisions daily, weekly, monthly, constantly. The better you can make the decisions you’re faced with, the better life you’ll likely live. Better is a relative term. I mean better to your circumstances. It’s possible for someone to make most every right decision and still end up with a not so great life due the circumstances they were born into. Not so great is better than awful. On the other end someone could make nothing but bad decisions and still do well because they were born into such privileged circumstances. However, it’s probably not as well as they might have ended up. These are edge cases. I think most people can change their circumstances through good or bad decision-making. Education helps you make better decisions and is a big part of why anyone learns and gains knowledge. You make better decisions when you have good balanced information from which to decide. You gain a certain amount of information to help you do specific things. For example how to develop a website with HTML and CSS. This is specific knowledge that not everyone needs to know. Then there are decisions we have to make daily where we don’t have much, if any, information to go on. Maybe the situation is completely new to you and you have no resource to draw from or maybe you have plenty of resources, but they can’t entirely be trusted. Maybe you just don’t have the time to acquire the information you need prior to making the decision. Education helps here by teaching you decision-making skills and giving you decision-making tools. It provides general knowledge you can use as a guideline in less than familiar situations where your specific knowledge is limited at best. Education helps you make connections between different disciplines, which can lead to both specific and general knowledge and skills. It gives you the confidence to apply information learned in one place to another or extract something common to both that can be applied in general to many different decisions. Where and how you acquire both specific and general education is irrelevant as long as you gain quality information and skills. It’s the quality of the education that’s important, not the source of the education. Every school I’ve attended in my admittedly small sample size of schools, has had professors, teachers, and assistants across a wide range of quality. I’ve had phenomenal teachers so good you’d have to try very hard not to learn something from them. I’ve also had truly abysmal teachers so bad you likely walked away knowing less than when you walked in. Most teachers are somewhere in between these edge cases. I’ve had teachers who’s style of teaching was similar to my style of learning. I’ve also had the opposite where we seemed out of sync. I always learned from the first, but not the second. It wasn’t necessarily the teacher’s fault or mine. It was the combination that didn’t work. Other’s in the same classes might have walked away with a different experience than I did. They might have meshed with a teacher where I didn’t or vice versa. Again every school I’ve attended, and I’ll go as far back as kindergarten, had all types of teachers and I walked away with a wide range of education from them. If I ranked all of them from best to worst, the best teachers weren’t always from the best schools and the worst teachers weren’t always from the worst schools. More goes into getting an education than where you did or didn’t go to school. Harvard University vs. Insert Random College Here The comment that led to this recording compared Harvard University to a small town school in the middle of nowhere as proof that the where matters. Can a school like Harvard provide a better education than a small town school in the middle of nowhere? Absolutely. I think most people would agree with that. However, the reverse can also be true. A small town school in the middle of nowhere can provide a better education than Harvard University. A quality education depends on more than the name of the school. It depends on the person, their effort, the specific teachers they work with and so on. The school most would say is better doesn’t automatically lead to the better education and who’s to say you wouldn’t learn more on your own and at your own pace than by going to any school, Harvard or otherwise. A formal education gives you more of the theory side of learning. While I consider theory very important, it can never replace real life experience. It can’t replace the doing. Both work best when you learn both ways, a case of the whole being greater than their sum. Aside from specific careers that require a degree and probably licensing, you’re in school to learn how to learn. The specifics you pick up are useful, but learning doesn’t end in school. It continues throughout life. It should happen more out of school than in school, because most of your life will happen outside of school. Schools are there to teach you how to think for yourself and how to learn on your own. Not everyone needs to go to school to learn how to learn or think. Some are pretty good doing both without a formal education. Closing Thoughts My apologies if any of my qualifications came across as boastful. They weren’t intended that way. If it means anything, I do exactly nothing with either of the degrees I earned. The work I do comes from things I’ve taught myself how to do and a lot of hard work. It comes from continued learning. People are different. We learn in different ways. I can read a text book on my own and come away having learned the subject matter as well as anyone who sat in on the classes. I guarantee I can do as well if not better than most of the students on test written by their teacher. I learned to be a good test taker years ago. Some people don’t learn from books alone and need the classroom. They need a person teaching and the structure of a formal course. Some people learn best outside that formal structure. They learn better away from a school environment. Different professions require different knowledge and skills, some of which can’t be learned in any classroom. Some things you just have to pick up as you go. None of these are better or worse. They’re just different ways of learning different things. Whatever it is you do, it doesn’t matter where you learned to do it. What matters is that you learned to do it and continue to learn to do it better. I think the education you receive has far more to do with you and the work you put into learning than where or how you receive it. It’s not about what school you did or didn’t go to. It’s about the quality of your education. That doesn’t mean teachers aren’t important. They are. They’re part of one of the most important professions there is. A good teacher will help you learn more and better. Your effort is still more important, though. There is no one right way to learn and there is no one right place to learn. The right or wrong is the choice to learn or not learn. That was the point I was trying to make in my previous post. Hopefully I did a better job making it this time around. Download a free sample from my book Design Fundamentals. The post Learning Is More Than Where You Get An Education 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., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States

HTML5 Structural Elements—Sectioning Elements - Vanseo Design

---

HTML5 Structural Elements—Sectioning Elements Posted: 23 Feb 2015 05:30 AM PST Are you using any of the new HTML5 structural elements in your work? Have you replaced div class=”nav” with the nav element? Do you know when to use elements like article, section, and aside? I’ve been asking similar questions the last few weeks. First I provided some context by looking at the document outline we’ve been working with for years and then I walked through how the HTML5 document outline was meant to work. So far in the series, I’ve kept talk the new elements in check to focus on the document outline. I’ve used only the <section> element in examples. It’s time to talk about the other elements. Today I want to talk about the new sectioning elements (section, article, nav, and aside). Next week I’ll talk about some non-sectioning elements (header, footer, and main). First, let’s talk a little about how these specific elements came to be. The Origin of the New Structural Elements According to Luke Stevens, author of The Truth about HTML5, the new elements were chosen somewhat arbitrarily. Ian Hickson and other contributors in the Web Hypertext Application Technology Working Group (WHATWG) noticed that many developers added classes to divs with similar names. class=”header” class=”footer” class=”nav” class=”sidebar” I’m guessing you’ve written each of the above at least a time or two. I know I have. They’ve been a part of most every website I’ve built for the last 10 years. The contributors thought why not turn these classes into HTML elements. It certainly makes sense and seems like a good idea. A couple of years later they did some research into how often these classes were used in order to justify the decision to create the new elements. I’ve seen others suggest that you shouldn’t use any of these elements because of their arbitrary origins, but seriously who cares. Do you avoid using post it notes, because the inventor was trying to make a super strong glue and accidentally ended up with the opposite? Of course not. I write class=”header” all the time. I don’t mind using an element named header instead. I think it made perfect sense to create these elements, no matter how the initial idea was formed. However… While I think the new elements make sense, there are some problems with them. The element definitions are sometimes different than how we’ve all used the classes and ids that inspired them. The new document outline suggests some less than clear uses cases for how the elements might be used. The new elements are confusing to use in practice. I think the latter two issues arise from the first. Had the definitions stayed truer to how we used the classes, most of us would probably be using the new elements in practice all the time. It seems to me the new structural elements are a good idea poorly executed. HTML5 Structural Elements and Assistive Technologies Each of the new elements maps to an ARIA role. For example the nav element maps to ARIA role=”navigation” and it communicates the same thing as the role to assistive devices. The topic of ARIA roles deserves it’s own post or series of posts, so I won’t go in-depth here. However I do want to look at the definitions of the ARIA roles that the new elements map to in order to see if they offer more about using the elements. I’ll save the deeper look at ARIA roles for another time. Here are the four sectioning elements and the ARIA role each maps to by default. You can see some of the elements and roles have the same name and others don’t. section maps to role=”region” article maps to role=”article” aside maps to role=”complementary” nav maps to role=”navigation” You can override the defaults, but if you don’t add a role to any of these elements, know they’ll communicate the semantics of their default roles. You should also know the not every browsers maps the new element to an ARIA role. For example IE11 supports none of these mappings. You shouldn’t count on the element communicating the semantics of the role just yet. Recommended practice is to use both if you want to communicate to assistive devices. 1 <nav role="navigation"></nav> We’re looking at ARIA roles here not so much for how to use them. Again I’ll save that talk for another time. What we want here is to understand how the roles are defined so we can better understand how and when to use the new elements. Sectioning Elements You use one of the four sectioning elements (section, article, aside, and nav) when you want to start a new section in the document outline. Each of the sectioning elements has a specific purpose beyond creating a new section, though. The section Element As we saw last week, the section element is meant to enclose a chunk of related content. It’s the most generic sectioning element and at first glance you might think of them as a more semantic div. It sounds easy enough. Where you might have previously wrapped a div around some related content, you might now use a section element instead. You wouldn’t just replace all your divs with sections as some divs are structural and some are presentational. More likely you would use the section element as we did in examples last week. 1 2 3 4 5 6 7 8 9 10 11 <section> <h1>Heading 1</h1> <p>Some text</p> <p>Some text</p> <section> <section> <h2>Heading 2</h2> <p>Some text</p> <p>Some text</p> <section> The section element maps to the ARIA role=”region” and a region is defined as: A large perceivable section of a web page or document, that is important enough to be included in a page summary or table of contents The role is defined more specifically than the element. A section can wrap any related content, but a region should only be for content that would also find it’s way into a table of contents or page summary. It suggests that sections shouldn’t be used as generically as they first appear. There’s also a recommendation to add a heading to every region and reference the heading with an aria-labelledby, which connects the section with the text that refers to it. In other words there should be a header inside every section and at least one heading inside that header. Until seeing the definition of the region role, I wondered why it was recommended to add a heading to each section, but now I see its goal is to help assistive devices understand and navigate content. If we limit sections to the importance described by the region role, placing a heading inside makes more sense. The article Element An article is similar to a section in that it should enclose a chunk of related content, however, the content inside an article should also be self-contained and independent. You should be able to reuse an article and have it make sense if it were published elsewhere. Publishing a blog post in an RSS feed is one example. However, the article element isn’t specifically for articles as written pieces of content in a magazine or on a website. An article in HTML5 is anything self-contained and independent. It’s an article as in an article of clothing. Comments on a blog or posts in a forum thread are examples where you might use an article element. In the case of comments you might have one article wrapping both the written post and all the comments and then each individual comment would also be an article. 1 2 3 4 5 6 7 <article> main text here with multiple sections, headings, etc. <article>Comment</article> <article>Comment</article> <article>Comment</article> </article> I find this definition, or at least the examples, confusing. I wonder how independent something can be if it first exists nested inside something else. How many comments make sense when removed from the blog post? How many forum posts make sense when removed from the thread? The independence of a comment has more to do with the content of the comment and not that it is a comment. I think the majority would lose their meaning and not be so independent. The article element maps to the article role, which is easy to remember. The role is defined similarly to the element in that it’s meant to be something independent. According to the role definition, independence is meant in the sense that an article’s content can stand alone, however, the element in question could still have associations with it’s ancestors. This helps explain why a blog comment or forum posts can be an article. It also allows you to add meta information such as the name of the author and a timestamp to a blog post without that meta information also applying to the comments on the post as the comments are independent articles. I’m still not 100% on board with the idea of nesting articles, but the definition of the role at least helps me understand it more. The aside Element An aside is meant to wrap a chunk of related content that is tangentially related to the content in the main outline, but not actually part of it. For example a call out in an article, that’s nice to know, but not essential for understanding the article. The spec offers examples like pull quotes and sidebars, but also suggests wrapping groups of nav elements, which I have a harder time seeing. I understand why a table of contents is considered tangential and related, but I question the need to wrap a nav element with another element as opposed to adding a role. The aside element maps to the ARIA role=”complementary” and it’s defined as a supporting section of a document, meant to be complementary to the main content. Content with a role of complementary belongs at a similar level in the DOM hierarchy as the main document, but still remains meaningful when separated from the main document. Examples might include widgets like show times, weather, sports scores, and stocks on a portal page. Yahoo or MSN home pages for example. If the complementary content can be completely separated from the main content, it might not be complementary and it might be better to use a more general role. This suggests that an advertising block, often given as an example of an aside, might be better structured as something else. I suppose given today’s online advertising that any ad appearing on a page is probably related to the content of the page, but since those ads can easily be separated from the content something else probably makes more sense. Given ad blocks are both self-contained and independent, an article might be the better choice, though it feels wrong to mark up a block of ads as an article. Then again with today’s native advertising, the two aren’t as different as they should be. The nav Element The nav element is meant to wrap groups of links that form navigation linking to different parts of the page or other pages on the site. However, just because you have a group of links it doesn’t mean it belongs inside a nav element. Global navigation is a good fit. A section menu or table of contents are also a good fit. Footer and utility links are probably good fits as well, though the spec specifically mentions footer links as not belonging inside a nav element and being fine inside the footer element only. The nav element maps to role=”navigation” and the definition of the role is pretty much the same as the definition of the element, a collection of links for navigating either the document or related documents. The nav element is probably the easiest element to understand and use. It’s definition (both element and role) is what you’d expect it to be. Closing Thoughts That takes us through the four new sectioning elements. The nav element seems straight forward, but I have some questions and reservations about the definitions and suggested use cases for the other three. I don’t know if the ARIA definitions played any part in the definitions of the new elements, but I find the ARIA definitions more specific and helpful. They seem to provide details lacking in the element definitions and use cases. I’m still not 100% sold on everything about the HTML5 sectioning elements, but I do feel better prepared to make a decision about them in practice (mostly because of the role definitions). I’ll let you know in a couple of weeks when I present a demo where I try to use these elements. Next week though, I’ll continue with the non-sectioning elements (main, header, and footer) and the ARIA roles associated with them to see if we can sort out how we’re supposed to use them. Download a free sample from my book Design Fundamentals. The post HTML5 Structural Elements—Sectioning Elements 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., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States

How We’ll Design and Develop Websites In A Few Years - Vanseo Design

---

How We’ll Design and Develop Websites In A Few Years Posted: 19 Feb 2015 05:30 AM PST Are you excited about the future of designing and developing websites? Are you looking forward to working with something like flexbox? Maybe it’s CSS masking, filter effects, or blend modes that you can’t wait to use. Note: This post includes an audio version. If you don’t see the audio player above, Click here to listen. You can also subscribe in iTunes After recording last week’s show on responsive layouts, I started thinking about how designing and developing websites has changed since I’ve been part of the industry these last dozen or so years. I’d like to talk about a few things on the way and how I see them changing the way we do our work. If you were part of the industry when it shifted from table-based layouts to CSS driven layouts (or even the more recent shift to responsive layouts), you might have noticed those who are first to use these new techniques are often able to use them as a competitive edge. It probably makes sense to start learning some of what’s coming, if you haven’t already started. Since I’ve been talking layouts, let’s start there. Improved Methods for Layouts Floats have been the predominant method for site layout for quite a few years. They’ve been that way nearly all the years I’ve been been building sites. Floats aren’t really an ideal solution, though. They’re better than what came before, but in all honesty and where layouts are concerned, floats are as much of a hack as tables were. Neither was created with the idea they’d be used for site layouts. Floats are really there to allow text to flow around around other content. They’ve worked well enough, but they’ve always had problems and some new problems specifically now that we’re working with responsive layouts. Fortunately, new and better things are on the way. Some of you probably remember an article that appeared on .Net Magazine a few years ago on The future of CSS layouts. The article, now on a new domain, talked about some of what was coming in CSS. Flexbox Multiple columns CSS grids Exclusions Regions I’ve written about all of these in the past. Check the links directly above if you want the details for how to work with them. Maybe I’ll revisit some to see if and how the spec has changed since I last covered them. Flexbox is the closest to being ready. It has good support and can be made to work with all the browsers and versions you likely need to work with. It’s a little extra effort for some browsers, but flexbox can work where you need to support it. I think flexbox is going to replace our current float-based approach to layouts soon, probably within the next year or two. I’m pretty sure the next version of this site will be built with flexbox. They solve one problem we’re running into with responsive layouts, that of being tied to our HTML source order. With floats, when your layout is a single column, elements will display in the order they appear in the source. Flexbox solves this problem and of course they’re flexible. It’s right there in the name. CSS multiple columns also has good support if you don’t mind using vendor prefixes. Multiple columns don’t work everywhere. The usual culprits have no support, but every other browser does, again with vendor prefixes. They’re an easy way to have multiple columns of text without having to build multiple columns in the layout. I suspect multiple columns will become more popular on wider screens when we have to decide what to do with all the extra space. We’re thinking lean and mean with our content now that we’re thinking mobile first. How do we fill the space on the widest screens. I think multiple columns will prove to be a good solution and the fallback is a single column. We’re certainly not going to use multiple columns of text on the smallest screens, but I can easily see how, as the layout grows wider to accommodate a wider screen, we’ll use multiple columns to fill the horizontal space I think CSS grids will prove to be even more valuable than flexbox. I took a quick look a couple of years ago and thought they were very promising. I’m going on memory, but assuming I’ve remembered correctly CSS grids offer everything flexbox does and more. Once I worked out how to use CSS grids in practice , I could easily look at my CSS and instantly understand how the grid was set up visually in the design. Unfortunately CSS grids still don’t have much support. IE10+ works with an older version of the spec and I was able to get CSS grids to work in Chrome Canary, but that was it. I’m guessing this is still 5–7 years down the road. I am looking forward to the time when it happens. Exclusions are what we wish we could do with floats. Imagine having something in the center of a block of text, and have the text flow around it on both sides. That’s one of the things exclusions can do. Combined with CSS Shapes, they also help us break out of the rectangle. Elements today are all part of the CSS box model which is a rectangle regardless of how an element appears. Create a circle with rounded corners and as far as your other elements are concerned, it’s still a rectangle. Other elements will flow around the rectangle and not the circle. Exclusions and shapes will change this. The outline of a circle will be a circle and not a rectangle. Exclusions will be fun and useful. I think we’ll all enjoy working with them once we get the chance. Note: In the recording I mention exclusions as being what breaks us free from rectangular boxes. My memory was off and it’s really the CSS shapes module that breaks us out of the box. Regions are another layout method, though I’m not sure if we’ll ever see them. There’s little, to no, current support and the Chrome team has no plans to add any. I don’t think Firefox has plans to add regions either, but don’t hold me to that. Regions are probably not going to arrive. At least it doesn’t look that way. Graphic Editing is Moving to Browsers Layout changes aren’t the only changes coming. I think a lot of what we do with graphic editors is moving to browsers. Whenever I talk about responsive images or images in general, I mention the need to reduce bitmap images on the web. They’ve always been a bottleneck and are usually among the biggest drags on a site’s performance. I typically suggest we should replace images with code where possible. CSS is giving us more opportunities all the time. It’s moving a number of things we think of as belong to a graphic editor to a browser. Clipping and masking Gradients CSS Filter effects Blending modes Light animation All of the above are possible with code (at least in some browsers). We can’t yet replicate with code everything that a graphic editor can do, but the CSS side is getting better. It’ll be interesting to see what else comes along and it’s probably good news for anyone making a graphic editor that runs in a browser. Improved Tools WYSIWYG tools have existed for a long time. The biggest problem with these tools has been the code they ultimately produce. It’s generally not the most performant code. It’s redundant. There will usually be excess markup and leftover CSS. The tools aren’t good at cleaning up and optimizing. The tools are improving though. Compare something like Macaw to the first version of Dreamweaver. Compare the latest version of Dreamweaver to its older self for that matter. On the Mac, there’s an app named Hype 2 that effectively replaces Flash. Adobe’s own Edge does the same. Adobe is reworking a lot of their tools now on Creative Cloud. The tools are getting better. I’d argue that in time hand coding will only be practiced by a few. It will be there more to fix and maintain sites and hand coders will be the exception rather than the rule. If you don’t believe me ask the programmers you know how many of them work in assembly language or directly in machine language. Ask them when was the last time they used punch cards to write programs. Things change. They evolve and become more accessible to more people. There are more visual interfaces involved with programming than there were years ago. WYSIWYG editors make developing websites more accessible to more people. It’s the same as what’s happened in programming and web development tools are likely to evolve in a similar way. New Processes and Deliverables Processes are something that are, or at least should, always be evolving. They’re often different for different people and teams, projects and clients. We’ve gone through a major change the last few years with the coming of responsive layouts. I think some of the process changes are settling a bit, but our processes will continue to evolve. Here are few things that are either part of your process now or will be before long. Version control everywhere More agile development That’s modular and iterative Deliverables in the browser More prototyping We’re realizing the connection between design and development and that both should be working together throughout the process instead of design coming first and development coming after. New Devices What about new devices like smartwatches? Will they gain mass appeal? I have no idea, but assuming they gain enough appeal what will it mean for how we think about websites? I saw an article recently about designing websites so they can be viewed and interacted with on a watch screen. I’m doubtful. I’m not so sure looking at a website is going to to be something we reach to smartwatches for, certainly not websites as constructed today. Even the narrow layouts we’re creating for phones will be too big to see on a watch screen. A smartwatch doesn’t say keyboard to me. It suggests more audio for input and maybe a handful of important gestures. I’m sure there are more input methods I can’t yet see or imagine. I can see how we’ll be thinking very different about interfaces in a few years, though. If you think designing and developing for smart watches will be more than five years in the future let me remind you the modern smartphone, with the introduction of the iPhone is barely eight years old. Content How will we think about content in the future? Will it still be in the context of a page or screen? Will it be something different. How we’re thinking about content is already changing. Content will become more modular. We’re asking if content needs to be on every device. If so, does it need to be in the same form? Maybe we have short, medium, and longer versions of some content for different devices. Does content need to be organized the same way on every device? Probably not. More sensors will ideally help us better understand a visitor’s context beyond the resolution or orientation of their screen. I’ve seen ux designers talk about moving from personas to use cases and workflows. There will probably never be a single answer to some of these questions. Perhaps more personalization is the answer. Search has moved this way and maybe websites need to as well in order to accommodate all the differences in people and contexts who visit our sites. Designing Systems I think this is good way to think about future of web design. We aren’t going to be designing pages as units and then connect those pages through navigation and other links across the site. We’re going to be designing systems that are capable of grabbing smaller units (chunks) of data and information and combining them in the “best” way for a particular context. I can see personalization here too. Perhaps this is where we’re heading, systems built to reconfigure themselves based on the desires and conditions of the person interacting with the system. The future of web design seems more about designing systems that can build “pages,” (for lack of a better term) on the fly from modular pieces of content. It sounds challenging, but also interesting. Closing Thoughts It might not feel like it as you’re reading or listening to this, but odds are how you design and develop websites in five or ten years time will be very different than how you do it today. How we do it today is very different than how I was designing and developing sites just three years ago, not mention another five to seven years before that when I was moving from tables to CSS driven layouts. In the dozen or so years I’ve been creating websites I’ve completely reworked how I build sites at least twice. It stands to reason that the next dozen or so years will bring even more change. I haven’t even mentioned mobile apps. Where will apps fit in all of this. I don’t think every site needs an app today, but perhaps that will change in the future. It’s likely that a website won’t mean quite the same thing it does today. It may not be the end all and be all to someone’s online presence. It may be just one way to interact with information, data and functionality. While some of the things I’ve talked here about are still a few years away, a lot you can work with now and there’s no time like the present to start learning and start asking questions. Think about where the industry is going as opposed to being comfortable where it is. Let me remind you again that people who are ready when technology is ready often gain a competitive advantage and can possibly make a name for themselves at the appropriate time. Download a free sample from my book Design Fundamentals. The post How We’ll Design and Develop Websites In A Few Years 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., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States

The HTML5 Document Outline - Vanseo Design

---

The HTML5 Document Outline Posted: 16 Feb 2015 05:30 AM PST The HTML 4 document outline, while easy to understand, has a few issues. It doesn’t allow for tangential content and it can be difficult to merge content from multiple documents. The HTML5 document outline and the new structural elements solve those problems in theory. Last week I began a look at the HTML5 outline and the new elements by looking at the HTML 4 document outline for context. I also talked about some of the problems with the outline and whether or not we should bother with the HTML5 document outline as it will probably never be in use. I think the HTML5 outline can still serve as context for trying to understand how to use new semantic elements like, section, article, aside, nav, header, and footer and it’s useful in that context. Today I'll walk through the HTML5 document outline and how it's supposed to work. Next week we'll get a little more in-depth about the new elements. I want to look at how each is defined in the spec as well as the use cases given to offer guidance for using the new elements. I also want to look at the ARIA roles each of the new elements maps to to further understand how to use the new elements in practice. HTML5 Document Outline The document outline we worked with prior to HTML5 (and still work with today) isn’t bad. It seems to have worked pretty well all these years, even if it’s not without some problems. You can’t always tell whether content belongs to a subsection or it’s parent section. Wrapping content with divs can help, but the divs offer no semantics without additional class or id names. Because everything is in a section in the document outline, it can be hard to account for information that’s related to the content in the main outline, but isn’t truly a part of it. It’s also difficult to take modular content from different documents and merge them into a single document. Content from one of the original documents will likely need to revisit it’s heading structure and tweak it so the merged content fits within the combined structure. The HTML5 document outline solves these problems with a new algorithm and some new sectioning elements that can be used to explicitly define a new section in the outline. <section> <article> <aside> <nav> Note: The main, header, and footer elements are not sectioning elements. Any of these four elements starts a new section of the outline within the parent element. The idea is to create a more understandable and logical structure, with better semantics. For example <section> is meant to contain chunks of related content. It’s the most generic of the new elements. We could replace the divs from one of last week’s examples with section elements. Here’s the example from last week 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <div> <h1>Bob Dylan Albums</h1> <p>Some text</p> <div> <h2>Blood on the Tracks</h2> <p>Some text</p> </div> <div> <h2>Highway 61 Revisited</h2> <p>Some text</p> </div> <p>Some text</p> </div> The HTML produces the following outline. 1 2 3 1. Bob Dylan Albums 1.1 Blood on the Tracks 1.2 Highway 61 Revisited We can replace all of the divs with section elements and produce a new outline. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <section> <h1>Bob Dylan Albums</h1> <p>Some text</p> <section> <h2>Blood on the Tracks</h2> <p>Some text</p> </section> <section> <h2>Highway 61 Revisited</h2> <p>Some text</p> </section> <p>Some text</p> </section> This example may look similar to the previous one using divs, but it does result in a slightly different outline. 1 2 3 4 1. Document 1.1 Bob Dylan Albums 1.1.1 Blood on the Tracks 1.1.2 Highway 61 Revisited The outline has a new section at the top called Document. It’s created by the initial sectioning element that wraps everything, which is the body element. Note: You can use either of the outliners below to check the document outline for your HTML. I’ll be using the first one throughout the series. HTML5 Outliner HTML 5 Outliner Here are both outlines again, along with the elements that create the new sections. It’s a useful feature of the first outliner and one reason I’m using it. Using divs: 1 2 3 1. Bob Dylan Albums <body><h1> 1.1 Blood on the Tracks <h2> 1.2.Highway 61 Revisited <h2> Using sections: 1 2 3 4 1. Document<body> 1.1 Bob Dylan Albums <section><h1> 1.1.1 Blood on the Tracks <section><h2> 1.1.2 Highway 61 Revisited <section><h2> Divs don’t signal a new section. They may be structural or they may be presentational. Section elements always signal a new section. This is true of all the sectioning elements and not just the <section> element. When using sections the heading is responsible for the text shown in the outline, but it’s the section element that’s responsible for creating the section. Here I’ve reworked the example a bit. I removed the paragraphs and changed the structure a little by wrapping the h1 in its own section and then wrapping it and first h2 in another section. 1 2 3 4 5 6 7 8 9 10 11 12 13 <section> <section> <h1>Bob Dylan Albums</h1> </section> <section> <h2>Blood on the Tracks</h2> </section> </section> <section> <h2>Highway 61 Revisited</h2> </section> The code produces this, perhaps surprising, outline. 1 2 3 4 5 1. Document <body> 1.1 Section <section> 1.1.1 Bob Dylan Albums <section><h1> 1.1.2 Blood on the Tracks <section><h2> 1.2 Highway 61 Revisited <section><h2> Once again the top of the outline (Document) is created by the body not shown in the code. The untitled Section comes from the section element that wraps both the h1, Bob Dylan Albums and the h2, Blood on the Tracks. Note that both are at the same level of the hierarchy. Regardless of the specific level heading used, the first heading inside a section is the main heading for that section. This is why both Bob Dylan Albums and Blood on the Tracks are at the same level in the in the outline. Both are the first heading in their respective sections. Also note that Highway 61 Revisited jumps back up one level in the outline. I’ll explain this momentarily, but first let’s compare the example to one using divs instead of sections. 1 2 3 4 5 6 7 8 9 10 11 12 13 <div> <div> <h1>Bob Dylan Albums</h1> </div> <div> <h2>Blood on the Tracks</h2> </div> </div> <div> <h2>Highway 61 Revisited</h2> </div> Using divs produces the same document outline as before, despite the code using a different HTML structure. 1 2 3 1. Bob Dylan Albums 1.1 Blood on the Tracks 1.2 Highway 61 Revisited Implicit Sectioning The first heading (regardless of it’s level) inside a sectioning element is the main heading for that sections. What about multiple headings inside a section. Headings that follow the first also create new sections like they do in HTML 4, but these sections are implied sections as no new sectioning element is introduced. Consider the following code. 1 2 3 4 5 6 7 8 9 <section> <h1>Heading level 1</h1> <h3>Heading level 3</h3> </section> <section> <h3>Heading level 3</h3> <h1>Heading level 1</h1> </section> Here I have two sections. Inside each section is an h1 and an h3, but they’re in reverse order in the two sections. The code produces this outline. 1 2 3 4 5 1.Document 1.Heading level 1 1.Heading level 3 2.Heading level 3 3.Heading level 1 The outline probably wasn’t what you were expecting. Once again the top of the outline is created by the body element (not shown). The first section nests the h3 one level below the h1, which is probably close to what you would expect. However, in the second section both headings are at the same level in the outline. The h1 in the first section and the h3 in the second are at the same level in the hierarchy, because each is the first heading inside its section. Each is effectively an h1 despite one being written as an h3. The second heading inside each section also creates a new section. The section is implied, since there is no new sectioning element. When the h3 follows the h1, the h3 is nested one level down. When the h1 follows the h3, the h1 stays at the same level in the hierarchy. Remember the h3 in the second section is acting as the top level heading (h1) for the section. Despite the actual heading used, the document outline sees two top level headings. This behavior is to ensure backwards compatibility with all the HTML 4 on the web. You’ve seen the difference in the outline when using divs and sections. Any heading that isn’t the first heading of its parent sectioning element becomes a new implicit section according to three rules. If the second heading is of lower rank (h3 vs h1 in the example), it becomes an implicit subsection. If the headings are the same level, the first section is closed (explicit or implicit) and a new implicit section at the same level is started. If the second heading is a higher level (h1 to h3 in the the example) the section (explicit or implicit) is a closed and a new implicit section starts one level higher in the outline. The last rule explains why the h2, Highway 61 Revisited jumped up a level in the example from earlier in this post. The specific headings used aren’t relevant. It’s the differences between them that are. Had I used h1s and h4s or h2s and h6s, the outline would be the same. Sectioning Roots Sectioning roots are HTML elements that create a new section on a separate outline. Sections inside a sectioning root don’t contribute to the main outline of ancestor elements. The body tag is a sectioning root without an ancestor. Other section roots are: blockquote figure details fieldset td In the following example, the blockquote is a sectioning root and so it’s content won’t be included in the main document outline. 1 2 3 4 5 6 7 <section> <h1>Bob Dylan Albums</h1> <blockquote> <h1>Bringing it all Back Home</h1> </blockquote> <h2>Blonde on Blonde</h2> </section> As you can see the resulting outline doesn’t include Bringing it all Back Home. 1 2 3 1.Document 1.1 Bob Dylan Albums 1.1.1 Blonde on Blonde Closing Thoughts I covered how the HTML5 document outline is meant to work. Again it isn’t currently implemented anywhere and probably never will be. The outline does provide the context for using the new elements, though. Hopefully the examples here help make the outline a little clearer. If not use one of the outline checking tools I linked to earlier in the post. You can test my code or better test some of your own. A new section can be created explicitly with any of the new sectioning elements. I only used the <section> element in the examples to focus on the outline rather than the elements, but the other sectioning elements (article, nav, aside) will also create new explicit sections. A new section can be created implicitly with hx tags. The first heading inside a section will always be the main heading for the section and will effectively be an h1. Headings that follow start new implicit sections inside the parent. Sectioning roots such as a blockquote or figure also create new sections, however these sections are separate from the main document outline. Again if this still isn’t clear test some code in either of the tools I linked to. Testing your own code really is the best way to understand what’s going on. Next week I’ll continue and talk about all of the new structural elements. We’ll look at four sectioning elements (section, article, nav, and aside) and three non-sectioning elements (header, footer, and main). Each has a specific purpose beyond whether it does or doesn’t create a new section. Download a free sample from my book Design Fundamentals. The post The HTML5 Document Outline 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., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States

Stop Calling It Responsive Design—It’s Web Design - Vanseo Design

---

Stop Calling It Responsive Design—It’s Web Design Posted: 12 Feb 2015 05:30 AM PST If I ask what is responsive design what do you think about? Relative measurements like % and em over absolute measurements like px? Do you think of breakpoints? High resolution images, the picture element, and srcset? Maybe you think about deliverables in the browser or site performance on mobile devices. Note: This post includes an audio version. If you don’t see the audio player above, Click here to listen. You can also subscribe in iTunes Are all of these things really part of responsive design? I’d say no. Relative measurements and breakpoints are. The rest, not so much. About a month ago I was listening to the Responsive Web Design podcast with Ethan Marcotte and Karen McGrane. The particular episode was the holiday titled, Responsive Design Saves Christmas and at one point the discussion turned to site performance. specifically how some people think there are performance issues with responsive design. I think it was Karen who mentioned that responsive design doesn’t have a performance problem. It’s the web as a whole that has a performance problem. I completely agree and it got me thinking. When people talk about responsive design they’re not always talking about quite the same thing. People make comparisons, debate, and even have heated arguments with each other, but they’re often talking about different things that all seem to get included under the umbrella of responsive design, regardless of whether or not they should be. I think we need to be clearer what we mean when we talk about responsive design. What is responsive design? What do we mean when we talk about it? I think we need to do a better when it comes to being clear about what we mean. Responsive Layouts When Ethan Marcotte first shared the phrase responsive design he told us there were three core ingredients of responsive design. From Ethan’s book on the the core ingredients are: A flexible, grid-based layout, Flexible images and media, and Media queries If we limit responsive design to these three things, what we think of as responsive design is really responsive layouts. All three core ingredients are about layout. Instead of fixed-width layouts we create flexible layouts and where that alone isn’t enough we use media queries to rearrange boxes of content and make more significant changes. It’s the same thing with images. We make them flexible and then have methods, such as using the picture element, for swapping images when flexibility alone isn’t enough. The swapping images might extend past layout, but the rest doesn’t. A technique like lazy loading that you might use for performance isn’t specifically about responsive design. If you decide to use lazy loading, is it only because you’re working with a flexible layout or is it because you want to respect the bandwidth of your visitors? It’s done to solve an image and performance issue, not specifically a responsive issue. Expanding Responsive Design Responsive layouts have led the industry to think about many other things. We’re changing our processes and deliverables. We’re thinking more about performance. We’re talking more about concepts like progressive enhancement and mobile first. None of these things are responsive design. They all existed prior. Performance has been an issue with the web for as long as I’ve been building websites. My first client came to me to redevelop her site because it was too slow. I replaced a table-based, sliced and diced PSD, layout with a CSS-driven layout and reduced the time for pages to load from about 90 seconds to something like 6 or 7 seconds. Responsive design is pushing us to see past solutions we’ve grown comfortable with. It shows us that some of our solutions don’t work as well as we thought. We’re seeing old problems and solutions under the new context of responsive design. Responsive design as originally described by Ethan is about responsive layouts, but those layouts have caused us to take another look at every aspect of web design. Fixed vs flexible is so at the core of what we do that changing how we approach layouts requires a change in design thinking. This change happens to coincide with the move to mobile devices given it’s part of the solution to dealing with small screens. But not everything about mobile devices has to do with responsive design. While responsive design is really about responsive layouts, it’s also about rethinking everything we knew about web design and how we go about designing and developing websites It’s the understanding that your design is never going to look and won’t ever function exactly the same way for different devices, difference screens, different capabilities, and different use cases. This isn’t anything new. We’re dealing with many of the same problems we always have, but we’re now seeing everything within the context of responsive design. Arguing About Different Things When responsive design is criticized, it’s usually in comparison to something non-responsive. Detractors like to cherry pick to make the comparison that suits them. One common complaint is that responsive sites are slow to load and have performance issues. No, it’s not responsive websites. Websites as a whole are slow to load and have performance issues. It’s because we want our sites to do the latest and greatest and coolest stuff imaginable. We want to wow visitors. It’s not your responsive layout slowing down your site. It’s the time it takes for all the ads, images, media, tracking, social sharing, and every other 3rd party application that gets included that slows down your site. If you’re going to make the comparison, make a fair one. You can’t fairly criticize responsive design for shrinking large images and serving them to phones when fixed-width sites do the same thing. Just because we ignored the problem when developing fixed-width sites, it doesn’t mean the issue is specific to responsive design. Responsive design just made it more obvious that we had deal with the problem. Responsive design makes us more aware of the problem and at least the image is now flexible so it doesn’t break the layout after loading. Responsive Layouts are the New Minimum The only fair comparison to make is the comparison between the responsive layout and the fixed width layout I said as much a couple years ago and received a comment on a post about responsive always being appropriate I said a responsive site takes a similar amount of time to design and develop as a static site The comment I received said, “presumably you've never tried to design/develop, for example, a complex e-commerce site responsively.” Does it really take longer? What part of an ecommerce site is different because the site is going to be responsive? Is it more challenging to design and develop a layout for a product heavy site? Sure. It’s also more challenging if the site is fixed-width. It’s not the responsive part that makes the task challenging. It’s the amount of content that creates the challenge. Is it really easier to set a width in pixels as opposed to setting a max-width as a percent? It isn’t. It just takes some getting used to. Do media queries add extra time to a project? Sure, but that amount of time is mostly getting used to using media queries. After a a couple or three responsive sites, they don’t take much extra time. Some perhaps, but not much. Some of that time is offset by not having to write conditional comments to target a specific set of browsers. It’s offset by not having to tweak your CSS to make sure everything looks the same cross browser. It isn’t doubling or tripling the time. Maybe it adds an extra few percent to the time. A responsive site can become more and take more time to complete, but that has more to do with all the extras and all the new possibilities we’re aware of because of responsive design. You don’t have to do something even when you know it’s good to do. There are lots of things we should do, but don’t necessarily have to do. The last few years I haven’t done much with images beyond the basic max-width: 100% and height: auto. The images are flexible, but not doing more means people with poor connections are downloading the big image. It’s certainly not the ideal solution . It is the best solution my clients would pay for given what’s been possible. Before responsive, I would have used that same image and and placed it in a fixed-width layout. People on slower connections still had to download it. If anything the situation was worse before, because the image wasn’t flexible and broke the layout. Both responsive and static sites download the image This is not a responsive problem. It’s All Web Design I think we’ve reached a point where we can stop referring to responsive design as something different from web design or as a specific case of web design. It’s not. Responsive web design is web design. They’re now the same thing. It didn’t happen overnight, but designers and developers have embraced responsive layouts. The debate over fixed and flexible is already an old one. Responsive layouts are now an obvious solution to the flexible vs fixed question. It should be obvious to anyone who’s ever thought about the problem. I’m sure in 10 years there will be people still arguing that you should develop fixed layouts just like there are people today who argue that we should stop building css-driven layouts and stick with html tables. The debate will never entirely end, but it has for most of us. What happened is once we started using responsive layouts, we noticed a bunch of other things that could be improved. Responsive made us aware because it requires a big change in design thinking. The problems we’re thinking about aren’t responsive problems though. They were here before the phrase responsive design reached anyone. Responsive pushes us to see them and in some cases it forces us to see that we’d become too comfortable with some less than ideal solutions. Static comps are a poor deliverable. That was always true. It just became harder to ignore the problem when your comp is trying to show a responsive site. Static comps have never reflected what happens on a site. That simply became more obvious with responsive design. Closing Thoughts I think we should be more careful about what we mean when we say responsive design. I’ve slipped several times in this recording and probably will slip again in future recordings and writings. It’s hard to change, but we should be more clear. Are we talking about the three core ingredients of responsive layouts? Then let’s call them responsive layouts. Are we talking about the new way in which we have to think about design? Are we talking about something beyond building sites and layouts that are flexible and rearrange themselves at points? Are we talking about problems we thought solved that aren’t solved all that well? Are we talking about how we’re rethinking content and what new possibilities await us? Then maybe we need to call it web design. A responsive layout is the new minimum you’re required to supply, but the rest is just web design. They’re problems we’ve dealt with before and now have to deal with under the new context of being responsive. Download a free sample from my book Design Fundamentals. The post Stop Calling It Responsive Design—It’s Web Design 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., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States