The SVG Canvas, Coordinate System, And Viewport - Vanseo Design

---

The SVG Canvas, Coordinate System, And Viewport Posted: 30 Mar 2015 05:30 AM PDT When you see SVG images on the screen you’re viewing only part of the canvas on which they’re drawn and you view the canvas through the SVG viewport. Canvas and viewport are both independent and connected and their relationship can be confusing and lead to unexpected results at times. That is until you understand the relationship and how to control the connection. At the start of the year I began a series about scalable vector graphics, which covered some of the basics for working with SVG. At the conclusion of the series, I said I would revisit SVG throughout the year and build on what we learned. Today starts the first revisit. Here are the posts from the previous series if you missed any. SVG Basics — How to Work with Scalable Vector Graphics SVG Basics — How To Create Simple Shapes And Lines SVG Basics — Fills And Strokes SVG Basics—Creating Paths With Line Commands SVG Basics—Creating Paths With Curve Commands If you read the earlier series, you may remember I mentioned that if your SVG is being clipped you should increase the width and/or height of the <svg> element. Today I want to explain why that is. I want to talk about the SVG coordinate system, the SVG canvas on which you draw, and the viewport through which you can see an area of the canvas. When I first started looking into the SVG coordinate system and viewport, I found it hard to understand conceptually what was going. I think I approached the topic from an incorrect context. In my attempts to gain that conceptual understanding, I thought of a metaphor, which I’ll share throughout this series. Others have covered the topic well and provided different ways to conceptually understand what’s happening and I’d like to point you to a couple that I leaned on a lot working on this post and the two that will follow it. Understanding SVG Coordinate Systems and Transformations (Part 1) — The viewport, viewBox, and preserveAspectRatio SVG Coordinate System The first post above is the first in a three part series by Sara Soueidan. I’ll be covering what Sara covers in this post over the next few weeks. The second post above is part of an SVG tutorial by Jakob Jenkov. Jakob offers a lot of good examples that helped me figure out how this all works. The Metaphor Picture a canvas of infinite size. You can draw anything you want anywhere on the canvas and you can draw it at any size you’d like. This is the SVG canvas. Now imagine someone has built an equally infinite wall directly in front of the canvas. The wall stretches across the exact same infinite width and infinite height of the canvas covering every part of it. Since a wall directly in front of a canvas makes it difficult to see what’s on the canvas, the builders of the wall were nice enough to create a window and even better they’ve given us the ability to set the size of this window. This window is the SVG viewport. The builders didn’t stop there. They left us with tools so we can move the canvas around and decide what region of it will show through the window as well as how much of that region will show. These tools are in the form of attributes (viewBox and preserveAspectRatio) on the SVG element. I’ll talk more about the attributes over the next two weeks. Today I want to focus on the canvas, the wall, and the window and I want to start with the coordinate system they use. The SVG Coordinate System SVG doesn’t behave exactly the same as the CSS box model, but the coordinate systems for both work the same way. The origin (0,0) of any SVG coordinate system is in the upper left corner of the parent element, whether the parent is the body, a div, or some other container. When you create a new SVG element you create a new coordinate system that represents an infinite SVG canvas. The origin may be aligned with the top left corner of the parent element, but the canvas still stretches infinitely in all directions. The x-axis is positive moving to the right and the y-axis is positive moving down. Both axes also move negatively to the left and up. One thing to understand with SVG is there are multiple coordinate systems in play at the same time. Whenever you create a new SVG element, you create a new canvas operating in its own coordinate space as well as a viewport operating in its own coordinate space. The coordinate systems of each canvas and viewport pair will align with each other by default. They’ll appear to be the same system, but they aren’t and as we’ll see you can change how they’re aligned with each other. In practice the elements you create on the infinite canvas will be near the canvas origin, but in theory they could be anywhere. Nothing is stopping you from creating a circle and placing it 4 billion px to the right of the origin. In theory, the window too could be near infinite as you can set any dimensions you want. However, you only have fixed dimensions to set the window size so it will be of fixed size and once set, this coordinate system will remain fixed in space. User agents (browsers) will align the origins and axes of both of these coordinate systems by default, though you can change this alignment to suit your needs. The two system can be set in different units. One could be set in pixels while another is set millimeters or picas or inches or points or ems or any unit you can specify for dimensions. The exception is %, which can’t be used. Again keep in mind that one of these coordinate systems always acts on an infinite canvas and another acts on what is a fixed window in space. The SVG Viewport You create a new SVG viewport whenever you create a new SVG element. The size of the viewport is equal to the width and height you set on the SVG element. 1 2 3 <svg width="600" height="300" style="outline: 5px solid #630"> <rect width="200" height="100" fill="#f00" /> </svg> Here I created a viewport that’s 600px wide and 300px high. Inside the viewport I created a 200px by 100px red rectangle. Since I didn’t specify units, pixels will be used as they’re the default. Because that’s what I usually want, I tend not to specify units as shortcut. I also added an outline the <svg> element in order to see the viewport boundaries.Here’s what the code produces. You can see a 5px brown outline that encloses an area 600px wide and 300px high. Everything inside the outline is the viewport. The lone graphic inside the viewport is a 200x by 100px red rectangle. By default the rectangle is located with it’s top left corner at the origin of the SVG canvas, which aligns with the origin of the viewport. One question I had was what size would the viewport be if you don’t set a width and height? I couldn’t find anything definitive. It’s up to each user-agent to decide the dimensions, but 300px by 150px seems to be the general default. I wouldn’t suggest relying on the default, though. Better to set the dimensions you want. Moving SVG Elements on the Canvas You can change where on the SVG canvas the rectangle is located by giving it x and/or y coordinates. Here I set both x and y to 10 (px) and you can see the rectangle moves away from the top left corner of the viewport. 1 2 3 <svg width="600" height="300" style="outline: 5px solid #630> <rect x="10" y="10" width="200" height="100" fill="#f00" /> </svg> Changing the x and/or y coordinates this way moves the drawn object on the SVG canvas. The canvas itself hasn’t moved and neither has the viewport. All I’ve done is drawn the same red rectangle in a different location on the canvas. You can also draw the rectangle so part of it is outside the viewport. 1 2 3 <svg width="600" height="300" style="outline: 5px solid #630> <rect x="-100" y="-50" width="200" height="100" fill="#f00" /> </svg> You can see here that most of the rectangle is no longer visible. Only the portion still inside the viewport can be seen. While I’ve only moved it a few pixels, in theory you could draw the rectangle anywhere you’d like on the infinite SVG canvas. Seeing Outside the Viewport One thing I don’t see mentioned often is why we can’t see anything outside of the viewport. The reason is the SVG element has its overflow property set to hidden by default so anything outside the viewport is hidden. Of course, the overflow property has some other values, including visible. 1 2 3 <svg width="600" height="300" style="outline: 5px solid #630; overflow: visible"> <rect x="-100" y="-50" width="200" height="100" fill="red" /> </svg> Changing the overflow property to visible lets you see the parts of the SVG canvas that are outside the viewport, at least the part of the canvas that fits within your screen (another viewport created by your browser). Now you can see the entire red rectangle, including the part outside the viewport. You won’t normally do this when working with SVG, but it can be a good way to help you understand what’s going on. Establishing a new Viewport Earlier I said there are multiple SVG coordinate systems in play at the same time. One for the canvas and one for the viewport at the very least. I also mentioned you can create new canvases and establish new viewports. Anytime you create a new SVG element, even one nested inside another SVG element you create a new canvas and viewport with its own coordinate systems. A handful of elements create new canvases and viewports. The <svg> element The <symbol> element when instantiated with the <use> element An <img> element that references an SVG file A <foreignObject> element Since we haven’t discussed these elements (aside from the svg element) yet, I’ll just list them for now. I mainly wanted reinforce that you can create multiple SVG canvases and viewports in the same HTML document. Closing Thoughts I’d like to stop here for today. It might not seem like I covered a lot of new things about SVG, but I want the conceptual understanding to sink in. The metaphor that helped me understand the concept is that of an infinite wall in front of an equally infinite canvas. We can see the SVG canvas through a window in the wall called the SVG viewport and we can control the size of this window. Next week I want to continue and talk about the first of two attributes we can use to move the canvas around and decide what part and how much of it to show through the viewport. I’ll look at the viewBox attribute and the following week I’ll talk about the preserveAspectRatio attribute. Download a free sample from my book Design Fundamentals. The post The SVG Canvas, Coordinate System, And Viewport 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

Why The Value and Perception of Design Don’t Match - Vanseo Design

---

Why The Value and Perception of Design Don’t Match Posted: 26 Mar 2015 05:30 AM PDT What do you think is the value of design? Do you think non-designers hold the same perception? I don’t. I think for most people the perceived value is less than the true value. Why? 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 Why are the value and perception of design so out of line with each other? Why the disconnect between the value we know we bring and the typical client’s perception of that value? About a month ago you may have seen a video that was shared on a more than a few design blogs. The video was a two minute montage showing graphic designers in movies and on television. Watching it you get a sense of how Hollywood portrays designers. While the video is specifically about graphic designers, I think the portrayal would be the same if it was showing web designers. It was not the most flattering portrayal. The montage shows designers in a very different light than how we would describe ourselves. For example at the end there’s a comment about hiring a designer for a logo, paying hundreds of thousands of pounds, and getting a squiggle in return. I think the portrayal unfair as I imagine you do as well, but I can understand where it comes from. Our clients don’t see all the work we do to create what might ultimately be a squiggle. They don’t see all the research that went into the choice. The client just sees the squiggle, knows he or she could draw a squiggle too, and wonders where all the money was spent. I doubt you think of yourself and your work the way it’s portrayed in the video so again I’ll ask why are the perception and value of design so out of balance and what, if anything, should we do about? The Value Designers Bring to a Design When a client approaches me to design and develop a site, these are some things I consider part of the design phase for the project. I consider myself designing when I’m engaged with any of the following. Client Conversations — Design begins as soon as I start asking my client questions about their site, their business, their customers, etc. Any thing I do to understand the problem I’m being asked to solve, is design. In fact problem definition is the most important stage of the design and different designers can get at the problem with different levels of skill and success. It may not come across as design, but get the problem definition wrong and no solution is going to work. You’ll be solving the wrong problem. Content — What is it? What will it be? How much will be on the site and how should it be organized? Which content has the most priority? What content types belong on each page? How many page templates will be needed and and what will be included on each. These are all important questions and their answers take considerable time and effort and are absolutely a large part of a design’s success of lack of success. Navigation — Once you’ve figured out how content will be organized on the site you have to figure out how visitors are going to find and access it. What should be included in global navigation? What will the labels of the menu items be? You likely can’t include every page in a global navigation bar so will there be secondary navigation inside sections? Will there be drop downs or flyouts on the main navigation? What other navigational patterns and structures will you need? Breadcrumbs? On-page navigation that serves as a table of contents? How about in-content links to other content? These navigational issues and their solutions don’t always come across as design to clients. Visuals and general aesthetics — Even where visuals are concerned much of the work is never seen. Choices in typefaces, layout, color, and imagery take time and effort. Prototypes often need to be created and modified to get feedback. Does a typeface communicate the right mood and feeling? What’s the best layout to display the content? Should it be a grid? What kind of grid? Do the colors and imagery convey the same mood as the type? What subtext is communicated by your aesthetics? Documentation — What kind of documentation is needed for the project? Will you create a style guide? What will the deliverables be and how often will you need to create them? Responsive issues — The last few years have added some extra things to our workload and have us rethinking the way we design. There are the obvious layout changes, but what about the extra image versions? Do some need to be cropped for smaller screens or included at all? Many of our clients probably aren’t aware of the extra consideration we have designing for a mobile world. Accessibility and user experience are design considerations that probably don’t get noticed as well. I’d include any developer topic we’re aware of as something included as design. For example some might not see performance as a design issue, but the visual choices we make certainly affect performance and what can be done to speed up a site, even if we never touch a line of code. Anything we can do to make development easier, whether we develop our own designs or have others develop them is probably something we should be doing and so becomes part of design. All the things we bring to a design add value. Do I know the absolute value? Can I put a dollar amount on it? Not really, but I certainly think a well-designed custom site is worth more than a generic design made to fit any business. There will always be more consideration given to project specific details in the custom design. Any of those details could be the one that convinces someone to buy or subscribe or whatever it is you hope they do when visiting. The Perception of the Value of Design I think the majority perception is that design is what it looks like. Design is blamed when the interface is confusing, but oddly seldom praised when it’s easy to understand and use. When the design works it’s assumed that’s how it naturally works. Design doesn’t get any of the credit. When it doesn’t work it’s because some designer got in the way of it working. Non-designers generally see design as making things pretty. They don’t value design for what it is, only for the shiny coat of paint on top. Because they see the pretty and not all the work we do, they can’t see all the value we bring. They can’t see us thinking about content and where to place it. My personal style is simple. I don’t use a lot of illustration or do the typical things you think of as aesthetics. I’ve had people contact me because they think I don’t spend much time on design and so my price should be low. I’ve had people looking to hire me for a site tell me it shouldn’t cost much because it doesn’t need design as they hand me a list of things that need design work. These people don’t become my clients, because I don’t take on their projects. Because much of what design involves isn’t included in the perception, design can seem overpriced. People think they’re paying us for how something looks and not for how we made it work. Simple, while good design, is sometimes seen as less valuable because it doesn’t include all the shiny. It’s important to understand. More illustration, more aesthetic detail is seen as more valuable and so understandably more expensive. Some designers with more aesthetic skills are seen as better designers, more for their illustration skills than design skills. They may or may not be better designers or have better aesthetic taste, but they have more skills making things look good and so are thought to bring more value to a design. Shrinking Markets At the start of the year I talked about why I think the market for freelance design services is shrinking and will continue to shrink. In many ways it results from the disconnect between the value design brings and the perception of what it brings. People who can’t see the value of design will choose cheaper options like Squarespace or Wix or commercial themes because their perception doesn’t include much of the value of design. The market pays for the value they perceive and not the value we think we bring. Why pay several thousand dollars for a custom design as opposed to $50 for a theme? If you only see the aesthetic coating and like how a particular theme looks, why would you pay more for custom work? The market for freelance web design services is segmenting. The majority don’t see value in design. They don’t see why one design is better because so much of the value in a design isn’t directly visible. I don’t think everyone holds this perception. There are certainly some who know design is more than how something looks and that it’s also how it works. The majority don’t see that, though. They can’t see in advance that your questions will get to the heart of their problem so your solution solves the right problem. They can’t see the semantics you’ve added for assistive devices. It’s all just a jumble of code. Clients want to pay the least they have to and not feel like they’re getting ripped off. The majority see web design as a commodity, something they need with little to distinguish one solution from another with the exception of how it looks. Those people are going to choose the least expensive option in most cases. The main thing they can see is the pretty and the wow and adding insult to injury, they often won’t have the same level of taste we do. Taste is part of what makes a designer a designer. It’s as much a skill or talent as anything else we do. Clients want your designs to stand out based on how they look, but probably to a lesser standard of quality to what you or I might know is good. That makes themes and DIY builders look even more attractive because they’re likely built to a mass aesthetic. What Should You Do About It? If client’s don’t see all the value in design what should you do? Years ago when this site was on a different domain and I was just getting started as a freelancer, I had pages on the site trying to convince people of the value of design before convincing them to specifically hire me. It didn’t take long to see it wasn’t worth my time to convince people of the value of design. It’s more efficient to find more people who already see the value than to convince those who don’t. You have to appeal to what your client thinks is the value you bring as opposed to trying to convince them of value they don’t see. Sell your services based on what most people see as the value you bring, which is the way your designs look. They have to at least be better than commercial themes and DIY site builders. I think the market is varied and there are and always will be people who understand the value of design. I suspect these people will choose larger agencies over freelancers or bring design in-house. Those who stick with freelancers will choose the designers who stand out the most which will often be those who create aesthetics that wow. It only makes sense to appeal to what people think is the value in your services if you want to sell those services. If people perceive design as how it looks then you should get better at making your designs look better. You can’t stop doing the things that design really is, but you have to offer something that appeals to potential clients to get them to choose you. Aesthetics are one way to differentiate one designer from another, especially given the perception of design. Those of us, myself included, who could improve on our aesthetic treatments should probably learn to improve our aesthetics. If not, you aren’t doing enough of what your client sees as the value you bring. This doesn’t mean every design should feature illustration or that we all need to go back to skeuomorphic detail, but it does mean you need to differentiate yourself visually from all the themes and templates and DIY site builders out there. Closing Thoughts There’s a huge disconnect between the value of design work and the perception of design and designers. You and I know all the different problems we solve when designing a website. Most potential clients don’t. They don’t see all the work in choosing fonts or color schemes or many of the other things we do. Some do, but most don’t. They only see the value in the visuals. They hold the perception that design is what it looks like. Do we need to change the perception? I’m not sure we could even if we try. It’s a difficult perception to change and it won’t change just because we consistently point at something and say this is good design, this is good design over and over. I think we should worry less about convincing the people who don’t see the value we bring and target those that already get it. At the same time we should understand most will see our aesthetics as the value we bring. Because people put so much emphasis on how things look, we should make our sites look better. I’m not sure exactly what that means given the different tastes among designers, let along clients, but I think we need to impress clients more with the the aesthetics we add a to a design. There should probably be something in the visuals that stand out and wow potential clients if we want to wow them enough to hire us. Download a free sample from my book Design Fundamentals. The post Why The Value and Perception of Design Don’t Match 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 — Series Wrap Up - Vanseo Design

---

HTML5 Structural Elements — Series Wrap Up Posted: 23 Mar 2015 05:30 AM PDT For the last month and a half I’ve been trying to better understand how to work with the new HTML5 structural elements with some degree of success as well as failure. Now that the series is done, what did I learn? I’ve talked about the document outline, the definitions of the new elements along with the definitions of the ARIA roles each maps to, and then I offered a demo and explained my choices for using and not using the new elements. If you missed any of the previous posts, here’s the entire series to this point. HTML Structural Elements And The Document Outline The HTML5 Document Outline HTML5 Structural Elements — Sectioning Elements HTML5 Structural Elements — Non-Sectioning Elements HTML5 Structural Elements — How I Built This Demo: Part 1 HTML5 Structural Elements — How I Built This Demo: Part 2 HTML5 Structural Elements Demo This is the last post in the series. When I started the series I’d characterize myself as something of a hostile witness to these new elements. I didn’t expect to find any reason to use them beyond this series. I was wrong and I thought I would conclude the series by sharing what I learned working on it and how I plan to incorporate the new sectioning and non-sectioning elements in my work. Document Outline When I finished the demo I thought why not check what the HTML5 document outline would be. I know it’s not in use anywhere, but I was curious and thought I’d take a look and see if I could learn anything. I ran my HTML through one of the outliners and here’s the outline that was returned along with the elements that create each new section. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 1. Document<body> 1. Section<section> 2. Navigation<nav> 3. Demo to explore html5 Structural Elements<article><h1> 1. Section<section> 2. Basic Structure<h2> 1. CSS Presentation<h3> 3. Thoughts About HTML5<h2> 4. Section<section> 1. About Steven Bradley<section><h3> 5. 3 Comments<section><h2> 1. Article<article> 2. Article<article> 3. Article<article> 4. Sidebar<aside> 5. Categories<nav><h3> 6. Connect<aside><h3> 7. Example Sites<aside><h3> 8. CSS Layouts<aside><h3> 9. Sponsored by<section><h3> The outline shows I’ve set up each block of content inside the header, footer, and sidebar at an equal level in the hierarchy to the article. I tend to think the main content of any page sits at a higher level in in the hierarchy than the boilerplate content, but that’s not how I structured my HTML according to the algorithm for the HTML5 document outline. Again the algorithm that produced this outline isn’t in use, but it does make me want to think more about how we structure content as part of the hierarchy. Should information in a sidebar sit at the same level in the hierarchy as the main content? I don’t know, but it’s a good question to ask and think about. If sidebar content should be at a lower level in the hierarchy, it suggests I should find a different way to markup sidebar content. For example changing div class=”sidebar” to aside class=”sidebar” places the sidebar container at the same level in the hierarchy as the article, but the content within the sidebar would be one level lower. 1 2 3 4 4.Sidebar<aside> 1.Sidebar<aside> 2.Categories<nav><h3> 3.Connect<aside><h3> I think you can make a case that this kind of outline makes more sense than the one I created with the structure I ultimately used. On any given page the content of the page should be seen as more important than boilerplate content. Of course, to follow through the rest of the boilerplate would need to be marked up with sectioning elements so header and footer elements wouldn’t make sense. I’m not sure which is the better structure, but it’s worth thinking about in this context. One of the things I learned these last few weeks is it’s worth spending more time thinking about the structure of our HTML and what it communicates. What I learned About HTML Writing This Series I sometimes mention how many posts here come about from my wanting to learn something. This series didn’t start out that way. I began what I thought would be a single post about the HTML5 document outline after a comment Jordan left on a post about why I don’t use the new HTML5 structural elements in practice. I may have thought it would be a single post, but something in the universe had other plans. The more I looked at the document outline and the new elements, the more confused I felt and the more research I did to try and clear the confusion. Comments by Šime on the first post in this series let me know I’d missed something important about the new elements where assistive devices was concerned. I went back for more research and rewrote much of the series at that point. All the research and revisions led to a lot of back and forth in how I feel about using the elements and how well I understand them. Both had me wondering if I would use the elements in practice once I concluded the series. As I reworked the demo and continued to discover more information, particularly the ARIA role definitions, I had a few realizations. There is a benefit to using the new elements, which is what they communicate to assistive devices. Despite what I still think are somewhat confusing guidelines for their use, if we as an industry use the new elements consistently we’ll give them more standard definitions through our use. The structural patterns I currently work with didn’t spring forth overnight. I’ve spent nearly a decade evolving these structures so why should I expect anything different with the new elements. A large part of my confusion comes from lack of working with the elements I want to understand. More practice should lead to more understanding. I know many of us like to think we’re always making objective decisions when we design and develop websites, but there’s a lot more subjectivity in our decisions than we might care to admit. The structure we choose for our HTML is also subjective. There’s no single right way to structure the HTML for a web page. Different developers will make different decisions that work. Take navigation as an example. I build navigation with an unordered list. Others use ordered lists. Two more common patterns for navigation bars are inline-blocks and CSS tables. Any of these approaches is fine. They each have a few tradeoffs that may or may not affect a specific project, but more likely each is used based on the personal preference of the developer. It will be the same with new elements like section and aside. We’ll need to work with them awhile to develop the patterns we eventually use and there will likely be several common patterns in use across the industry. Incorporating the New into the Old I did gain a new appreciation for the value and use of the new elements and I would like to use them more. I had forgotten, but I did use the HTML5 elements when I developed this site’s current design. I think the easiest way to use the new elements is to incorporate one or two at time into your work. A few of the new elements do replace a div and class combo you probably use and the new element is meant to work the same way. We can start by making the following substitutions. 1 2 3 4 <div class="header"> --> <header> <div class="footer"> --> <footer> <div class="main"> --> <main> <div class="nav"> --> <nav> You barely have to alter your CSS practices with these changes. Instead of .header you’ll write header (with or without an additional class). Same for the other three elements. From here you can experiment. With the header and footer elements you can decide if you only want to use them once each per page for site headers and footers or if you want to integrate them more through your document. Spend some time researching the use of headers wrapping h1–h6 headings at the start of any new section in the outline. Do similar with the footer element. Do you think a footer is a good call for meta information inside an article? Put in some time thinking about it and decide for yourself. You can always change your mind later. You can do the same with the other three elements. Enclosing your main content inside an article element is another painless switch. Whether to structure blog comments or forum posts as articles is a different question. Again, research, try, and think critically about the decisions you make. I had a hard time sorting out how to interpret related and tangential making both asides and sections confusing at times. Some of my confusion was my misunderstanding of the spec’s definition of related to what. It’s something I’ll continue to think about and I suspect as I gain more information and put more thought into the problem, I’ll come to a more confident decision about using asides and sections. I know I wasn’t an expert in using divs and spans the first time I used CSS for a site layout. None of us was. It’s the same with these elements and the structural patterns we’ll eventually settle into. One last thought for the future is to continue to check your document outline. Despite the lack of use for the HTML5 document outline algorithm, it can be a useful tool for seeing how you’ve structured your page and what you’re communicating with that structure. Closing Thoughts I learned a lot more than I expected when I started this series. I admit to going in as a hostile witness. I’ve come out the other side with a greater appreciation for and a greater desire to use the new elements more. At the start I didn’t see any harm in using the new elements, but I wasn’t seeing any benefit either. That changed when I learned the new elements communicate to assistive devices. If you’re still on the fence, I recommend coding a demo of your own. Develop one of your typical layouts for a web page and use the new elements when doing so. For each part of the document ask yourself what elements you might use and think about the pros and cons of each. I was able to work through a lot of my confusion only when making real decisions about what element to use. I’ll add one last reason for working with the new elements before closing. Sometimes it’s just good to shake up your routine. It’s easy to become too comfortable with a way of doing something. I found myself thinking about and questioning some of my common practices because I forced myself to change those practices with the new elements. If you take only one thing away from this series, take the idea that critical thought about how you structure your HTML is worth the investment. The new HTML5 elements give you a perfect opportunity to do that, especially if you aren’t yet working with them. I think many of us take the structure of our HTML for granted to some degree. We use the same patterns we’ve used for years and don’t consider if they could or even should be improved. Change for the sake of change gets you to question your current practices and think about a lot of things you possibly take for granted. Think of it as a spring cleaning for your coding practices. I hope you enjoyed this look at HTML structure. It’s been a few more weeks than I originally expected and I think it’s time to finally put this series to rest. Maybe I’ll report back after using the new elements more often in practice, but for now it’s time to move on to another topic. Download a free sample from my book Design Fundamentals. The post HTML5 Structural Elements — Series Wrap Up 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

Build A Process That Works For You By Stealing From Others - Vanseo Design

---

Build A Process That Works For You By Stealing From Others Posted: 19 Mar 2015 05:30 AM PDT Do you work from a process? I’m going to answer for you and tell you that you do. Everyone does whether they call it a process of not. If you go through any of the same steps across projects, you have a process. 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 Programming Note: I mentioned last week I ordered a new mic. This is the first show I recorded with it. Hopefully the audio will sound better, though it might take me a little time to get the settings on both the mic and the software just right. I have a process for writing. I tweak the process a little depending on whether I’m writing a blog post, a guest article, a series of posts, or a book. They all get written with variations of the same basic process. I also have processes for designing and developing websites. I have an idealized process when I’m my own client and I have a more flexible process when I’m working for real paying clients to account for the differences between them. Not long ago I listened to an episode of the Self Publishing Podcast. It’s a podcast for independent writers and publishers. Sean Platt, one of the hosts, mentioned the idea of talking DNA strands from someone else’s process. I caught what he said in passing and don’t remember the exact quote, but the gist was taking parts from how someone else does something and incorporating it into your own way. Hearing Sean led me to think about processes and for lack of a better word, mentors. I’m considering as mentors people you follow online and learn a lot from. These aren’t true mentors in the sense of the definition, but these are people who’s ideas resonate with you and who you follow to both listen to what they say and observe what they do. I not only read the blogs of my online mentors, I sign up for their newsletters, follow their social accounts, and generally pay attention to most anything they do as a way to learn. I may copy from them as a starting point or as a guide. Ultimately I learn from a handful of people and mix what I learn with what I think and believe. Everything gets incorporated into a process of my creation. I’ll listen to the advice of others, but in the end I get to make my own decisions. That’s what I want to talk about today. How do you learn from others? How do you find your process? How do you figure out what steps will work for you? This is My Process — Get Your Own You have to find your own process. You and I aren’t exactly the same. You aren’t exactly the same as anyone else. Neither am I. We’re all different and we all work best with different processes or variations of a few general processes. Everyone has to figure out the best way for them. When anyone shares how they do something, they share what works for them. You shouldn’t religiously follow what they do. Blind faith in anything is bad. You have to do your own thinking. You have to find your own process for design, development, writing, creativity, or life in general. Anything I share here about how to do something is really what I found to work for me. It may or may not work for you. Only you decide which are the parts that will work for you. Much in our processes will probably overlap. If you design websites you no doubt create layouts, develop color schemes, and make typographic decisions. All of these are part of both our processes, but we may do each differently. We probably do things with different levels of skill. Maybe your strength is working with color, while mine is working with layouts. We’ll both play to our strengths and minimize our weaknesses. I try to eliminate the latter where I can and I’ve found tricks here and there to help me when I can’t. When I talk about anything here, it’s my way of doing things and not necessarily the right way or best way of doing them. It’s the way I’ve decided is right and best for me at that moment in time. I change what I think are best and right often. If you’re trying to learn from me (or anyone) look at my process and take the parts of it you think will work for you and incorporate them into your own. Then find others and take a few things from them to incorporate as well. Weave all the parts you take from different people with parts of your own. Mix everything in a way that reconciles it with what you think and believe. Add it all together and mix everything around and you’ll have a way to do things that’s unique to you. That’s how the best artists steal. Good artists can copy others, but they don’t weave the different strands into a unique whole. They don’t add something of themselves to what they borrow from others. They just copy exactly as was done before. When I share things I try to explain not only what I do and how I do it, but why I do it as well. I want you to understand my thought process for the decisions I make. Answering the why helps make something more understandable. It gives you more ability to decide if what I say makes sense. I don’t want to encourage you to copy me. I want to encourage you to integrate the things you get from me into something of your own. How to Find Your Process If you don’t have something you think of as a process where do you start? What steps did you take to design and develop the last site you worked on? What steps did you take to write your last article? What steps did you take to convince your last client to hire you? List out the steps. That’s your process or a starting point for one. Now work to improve it. Find the weak points and learn to do them better. Divide one step into two smaller steps or combine two steps into a single step. I try new things all the time to tweak my process. I don’t look to change everything I do, but I do look to improve where I can. Sometimes it’s to help me be more productive. Sometimes it’s to bring more quality to my work. I observe, review, and think about my process consistently in order to continue to improve it. Sometimes I like the change and incorporate it permanently. Sometimes I discard a tweak as soon as I’m done with the experiment. Learn what you can from others. Ask yourself how does designer X present deliverables to clients? How does writer Y come up with new ideas? How does developer Z build the template for a web page. You don’t have to do exactly what they say or do, but think about how you might incorporate it into what you do. The answer might be contained in a different part of their process. You might have to look at the whole of their process to understand how they deal with a specific step. If you like what I write it might not be the writing. It might come about through the way I collect ideas or organize my notes. Listen to what your “mentors” tell you they do and think about what parts of their process might help yours. Go beyond listening to what they say and observe what they do. What they do is more important, but you need to the context of what they say for the most benefit. If you don’t agree with how someone does something don’t do that thing the way he or she suggests. You’re the one in charge of your process. You get to decide what’s in and what’s out. You decide how you do things. No one else’s process will work exactly for you. Pick and choose your process There are some people who like to take shortcuts (good artists borrow). They look at how someone does something and apply it exactly to their own work. They never think beyond copying. They’re looking for the easy way, the recipe to follow. At best this will work short term, but long term it won’t. It leaves you reliant on that other person’s method, without any idea how to adapt. You can’t take another person’s way and apply it exactly. You have to do more. You can copy someone else as a starting point, but you should expect to continue to tweak and modify until it’s your own (great artists steal). Iterate Your Process You can’t stop when you have something in place. You have to iterate your process and continue to make it better. Consistently review where you are, what’s working, and what isn’t. Be honest with yourself. It isn’t easy, but it is necessary. Only you can find what will work for you and only you can put in the effort to make your process better. Analyze what works for you and what doesn’t work. For example the mic I had been using for recordings didn’t have a pop filter and it picked up noise from my surroundings. With the new mic I also purchased a wind screen and a pop filter. Hopefully both help. I took something that wasn’t working and tweaked it. I bought new recording equipment to help my recording process. In this case it cost a little money and it will take a little time to get to know the new equipment and use it as best as I can. Improve the parts of your process that don’t work. Improve parts that do work. Discard some things and try something different. Do this consistently. Think critically about your process and how to improve it. Then improve it. It can take time to find your process, at least one you feel confident in. It probably won’t work quite how you want at first, but persistence pays off. Try, evaluate, learn, try again, but better. Don’t worry that one recording isn’t so good. Improve your process to make them all better. It’ll take time to find what works for you. You have to fail and make a lot of mistakes along the way to success. Don’t worry if a site or article doesn’t turn out like you want. The disappointment is good. It’s your taste expressing itself. It’s your gut communicating to you. Try to understand what your gut is saying. It’s telling you something isn’t quite right. Use that as motivation to get better. What didn’t turn out like you wanted? Was it a poor color choice or the wrong typeface? Fix that part of your process next time around. Learn how to identify what you like and don’t like and then figure out why? Think critically. When you like a decision you made, defend it. Have reasons for the choices you make. Identify what specifically is disappointing you. Learn how to do that thing better. Even a little improvement means you’ll disappoint yourself less. That you can express that you don’t like something in your work tells you you’re capable of getting better. The first step is being able to recognize good from bad. Have confidence in your recognition and use that confidence to guide the direction of your learning. A good process can help you be more confident because you have a process you trust and can rely on when you need it. Closing Thoughts I’ve been saying process a lot throughout this post, but everything I said is true of anything you learn in life. It’s your process. It’s your design. It’s your article. It’s your life. It’s up to you to decide what each is. “Life isn’t about finding yourself. Life is about creating yourself.” —George Bernard Shaw I’ve been coming back to this quote the last few weeks. Life is creating yourself. It’s creating a process to live by. It’s ok to start by copying those who came before you. Copy your parents, your friends, people you admire. Copying is a time honored tradition for learning. It’s ok as a starting point, but you can’t stop with the copying. You copy as a way to integrate what someone else shared into your whole. When you can combine what you like of those who’s work you admire and mix it all together with something of yourself, you find your voice. You find what differentiates you from your competition. You find your process for creating and producing. You find your way to be unique. No one can do things quite the same way as you because no one will pick and choose the exact same parts or combine them in the exact same way. And no one will be able to add the parts that are uniquely you. This process of copying and integrating is what Vincent van Gogh meant by being a link in a chain. He took from those who came before, mixed with something of himself, and left something for next person to take from him. The chain is the art, the painting. The links are the individuals who pushed art and painting forward by building on the work of those who came before. It’s also what’s meant by the quote “good artists borrow and great artists steal” Van Gogh learned (stole) from those who came before and left his work for others to learn (steal) from him. All artists whether painters, musicians, writers, or dancers copy their favorites and combine with other favorites and themselves to find their voice. Follow the tradition. Develop your own process for designing a website, writing an article, or living your life. Take what you like from the process of others, but remember only you can create a process that works for you. Again I hope the sound quality is better today. I’ll work to make it better and then I’ll continue to work and make it better. Download a free sample from my book Design Fundamentals. The post Build A Process That Works For You By Stealing From Others 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 — How I Built This Demo: Part 2 - Vanseo Design

---

HTML5 Structural Elements — How I Built This Demo: Part 2 Posted: 16 Mar 2015 05:30 AM PDT As I mentioned last week, it’s one thing to learn how to use the new HTML5 structural elements and another to actually use them. In the past I’ve found using some of the HTML5 elements like aside seemingly easy to understand, but more difficult to use in practice. So far in this series I’ve talked about the document outline we work with and the HTML5 outline that’s been proposed, but not used anywhere. I followed the outline talk with definitions for using the new sectioning elements and the new non-sectioning elements. Last week I presented a demo that uses these new HTML elements and started to share my decisions and reasoning for using the elements I did and didn’t use. I talked briefly about the overall layout and then offered more details about both the header and main content areas. Today I want to look at the other two parts of the layout, the sidebar and footer. I found both more confusing to structure mainly because the deeper I’ve looked at it the less I’ve understood what an aside really is. I’ll follow with some thoughts about how I used headings throughout. Here’s the demo again in case you missed the link above and want to follow along. The Sidebar The sidebar turned out to be more confusing than I expected. My initial thought was to wrap an aside around the entire thing, but the more I thought about it, the more I disagreed with using an aside. Is the whole sidebar related to the main document outline? If it is, it’s related in the same way the header and footer and all boilerplate content is related to the main document outline and should use an aside as well. One question I kept asking is what does it really mean to be tangentially related to something? And related to what? Is it related to the main content of the page or the main document outline, which is the entire page. The impression I originally got reading the spec is related means to the main document outline, but that starts with the body element. To me it makes more sense for an aside to be related to something a little nearer in the hierarchy. An aside in an article should be related to that article. An aside in a footer should be related to the main content in that footer. Note: In looking again at the spec and the definition for an aside (after finishing the demo), the tangentially related part is clearer than I was thinking: a section of a page that consists of content that is tangentially related to the content around the aside element Unfortunately it’s something I had forgotten when working on the demo, though it is where my thinking was leading. Some of my confusion about asides is clearly of my own doing it seems. It’s a good argument for reviewing what you think you know from time to time. It seemed more logical to me for the content inside the sidebar to be an aside, but the sidebar as a whole should probably be something else. I’m not sure that’s best, but it’s what seemed logical at the time. I thought about using a section as the sidebar container, but there’s no reason why every block of content inside has to be related. How are the subscribe link, the category navigation, and social buttons related to each other? They’re related through their connection to the whole site, but so is everything on the page. In the end I decided the wrapper is there solely to present what’s inside. It helps align elements within the layout. Since it’s for presentation only I went back to using a div and added the sidebar class for styling. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 <div class="sidebar"> <aside role="complementary"> <a class="rss" href=""><img src="" alt=""> Subscribe</a> </aside> <nav> <h3>Categories</h3> <ul> <li><a href="">CSS</a></li> <li><a href="">Web Design</a></li> <li><a href="">WordPress</a></li> <li><a href="">Blogging</a></li> <li><a href="">SEO</a></li> </ul> </nav> <aside class="connect" role="complementary"> <h3>Connect</h3> <ul> <li><a href="" class="twitter"></a></li> <li><a href="" class="google"></a></li> <li><a href="" class="linkedin"></a></li> <li><a href="" class="dribbble"></a></li> <li><a href="" class="pinterest"></a></li> </ul> </aside> </div> I decided to wrap both the RSS information and the social buttons with an aside (along with a complementary role), though I still have some questions about relatedness. What’s the content around the asides here? Is it the other aside and a nav element? Is it the container? When I used a div to wrap the entire sidebar I said the content inside wasn’t truly related to each other. In that case I shouldn’t be using an aside for the content inside. Either the content or the container would need to change to be consistent, but as you can see I opted for the inconsistency. The buttons are a list of links to external sites. The external part says a nav element isn’t appropriate and so again I chose an aside. The nav element made perfect sense for the category menu, however. I didn’t add a class like I did for the global navigation and opted for nested element selectors, though I probably would add a class in practice. Other than structuring the category navigation inside a nav element, I have questions about most everything I did here. I could easily change my mind about everything by tomorrow. My main question with asides is still to do with their relatedness. The spec is clearer than I originally thought about what an aside should be related to, but in practice I still find myself getting tripped up. The problem is related and tangential are subjective words. Is a list of recent posts tangentially related to to the post that serves as the main content on the page? I don’t think so, but some would probably say it is. Both are related to the blog as a whole, but not to each other beside the general blog connection. Change recent posts to related posts and by definition they’d be related. Perhaps I’m overthinking things. A simpler approach with the sidebar might have been to wrap everything with an aside and then structure the rss link and social buttons as sections. In the end I think the question to decide is what is your definition of around the aside. Deciding the container should be an aside means you’re comparing it to the main content and other boilerplate on the page. Deciding the content in the sidebar is an aside means you’re comparing it to the content in the same container. The Footer The footer was another area of confusion for me, though much of the confusion was of my own doing. The content I placed inside the footer isn’t exactly indicative of the kind of content I would place in a typical fat footer. In the original demo the three blocks of content on the dark gray background were not inside the footer element. They were inside a separate div with an id of footer. I was thinking of them as something unique to the page and not necessarily the whole site. This time around I decided to code this area as though it was a site footer and not for the page only. Some of the content in the footer is page specific, though. Having a little of both site footer and unique page footer threw me off when I was making decisions about how to structure everything. What probably makes more sense is to treat everything inside the gray background as another sidebar and structure it similar to the way I just described in the section about the sidebar. The footer would consist of the copyright and credit information only, which again is how I did it the last time. Instead I chose a footer element (with contentinfo ARIA role) that includes both the gray background and the copyright information. Because I wanted the copyright outside the gray background, I wrapped everything inside the gray area in a div. The background is presentational only and the content in each block isn’t related to the other blocks. For both reasons a div made more sense to me than a section. 1 2 3 4 5 6 7 8 9 <footer role="contentinfo"> <div> <aside role="complementary"></aside> <aside role="complementary"></aside> <section class="advertising"></section> </div> <p class="copyright"></p> </footer> Originally I structured each of the three blocks as an aside, though see my questions from the sidebar section about what’s related to what. After reading the definition for the complementary ARIA role, I decided the ad block shouldn’t be an aside, since it can be completely removed from the main content. It doesn’t support the content and could easily placed on another page with different content without any loss in meaning. Instead I wrapped the ad in a section. In the demo there’s a single ad, but it’s easy to imagine several ads here related to each other by being ads. The other two blocks I left as asides, though again see my questions about what’s related to what. Some of my specific confusion here is the way I mixed page specific and site specific content in the footer, but much isn’t. I still haven’t answered the related questions for myself. Inside each aside is a heading (h3), a paragraph, and a list of links. I didn’t wrap the links with a nav element. The example sites link to external sources, and the layouts aren’t really navigation as much as a few recommended links. Headings In this demo I opted to use headings as I always have. There’s a hierarchy of h1–h3 tags inside the article. Headings inside the sidebar and footer are all h3s. I don’t know if h3s are the best choice, but it was my choice I’ve never settled on a best practice for headings outside of the hierarchy of the main content. I don’t use h1s outside of the main content. I sometimes use h2s, sometimes h3s, and occasionally h4s. My choice is usually based on what’s easier for me at the moment, which isn’t a good way to choose what level heading to use. I decided not to use header elements around headings at the start of sections. After learning about the ARIA region role, a better choice would probably have been to use headers around headings in the article as each would likely be included in a table of contents for the article. My reason for not using headers around headings was the extra markup. I would think there’s another way to communicate the same semantics to assistive devices and it’s something I’ll look for. The rationale for using headers makes sense to me if they help assistive devices, but I’m not sold on the implementation just yet. In the end I stuck with the same old for how I used headings in the demo. I’ll consider the idea of using headers to help assistive devices or I’ll look for another way to communicate the same information. In other words I still have some things to work out where headings are concerned. Closing Thoughts The sidebar and footer were definitely the areas of this demo that were the hardest for me to structure. I went back and forth a number of times on both. The sidebar was both an aside and section before I ultimately decided to use a div. The footer went through similar changes. Most of my confusion with both stems from questions about what we’re comparing when we decide if something is related. I suspect I’ll need to think a lot about the question before coming to any decision. The definition seems clear enough, but the definition suggests that asides only ever live inside the main content of a page even though typical sidebars are mentioned as a common use case. I’m surprised, because prior to this series, an aside was one of the elements I thought I understood well. The deeper I look, the more confusion crept into my thoughts. It’s possible I’m overthinking their use. Next week I want to finish talking about the demo and the series itself. I want to share what I learned working on this demo and from the posts that preceded it. I also want to share how I plan to work with all the new elements in the future. I’ll leave you with a few closing thoughts to wrap up the entire series as well. Download a free sample from my book Design Fundamentals. The post HTML5 Structural Elements — How I Built This Demo: Part 2 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