Happy Thanksgiving — Images, Art, And Lego In New York - Vanseo Design

---

Happy Thanksgiving — Images, Art, And Lego In New York Posted: 28 Nov 2013 05:30 AM PST Happy Thanksgiving to those of you in the United States. A belated Happy Thanksgiving to those of you in Canada. Happy Thursday to the rest of the world. Following my usual tradition I’m visiting family in New York this time of year and as with tradition I thought I’d share a few of the images I’ve captured while here. Unlike previous years, the weather hasn’t wanted to cooperate and present conditions conducive to photography. We had to skip a few of our usual site seeing spots this year, but I did my best to capture some images. Here are some Thanksgiving posts from years past if you’re in a photography viewing mood. Thanksgiving 2012 Thanksgiving 2011 Thanksgiving 2010 Thanksgiving 2007 Christmas in New York Seeing the city filled with decorations and especially seeing the department store windows set up for the season lets me know the holiday season is upon us. Maybe it’s from growing up here or from all the holiday movies set in New York, but there’s something about Manhattan this time of year. The first two pictures below are from the Macy’s windows. If you look closely at the second image, you can see my reflection taking the picture. The next two images are from the Lord and Taylor’s display. There were a handful of small windows with the artist’s mannequins that I really enjoyed. I wish it was easier to get pictures of the store windows, but with all the people getting in close to take a look and the way the windows pick up reflections of everyone walking by, it’s more difficult than you might think. Buildings in the City Some rainy weather made it hard to get pictures as we walked through the city and since I’ve shown buildings so often I figured I’d hold back on most of the ones I captured this time around. I did get two I liked and thought I’d share though. In the first I liked the way the one building curves out near the ground. I’m not sure what building it is and don’t remember quite where we were when I took the picture, but there’s something about the building that made me want to get the image. The second image is an interior of the New York Public Library. We don’t usually spend a lot of time in the Library, but this year we did. So much seems to be happening in this one little corner looking up toward the ceiling. Camera Experiment in Times Square A few years ago I left my camera behind and starting taking pictures exclusively with my iPhone. One thing I haven’t really done is learn how to use to iPhone’s camera better. I typically point, frame a composition, and click. I recently bought an iPhone 5s and thought this year I should start learning to use the camera better. My first experiment was to play around with the lighting by tapping different portions of the image before taking the picture. Below are the results of three experiments in Times Square as afternoon was becoming evening. On the left of each is the default lighting the camera chose. On the right in each is the result of tapping on a darker are in the picture to capture more of what was in the shadows. The last image below shows the difference the most. You can see how much more detail is captured in the building, but also how much the sky gets blow out. I didn’t think of it till after we were home that night, but I probably should have been taking the pictures above, in fact most of the outdoor pictures from this day, using HDR, which would have combined the images at several exposures. Art Because the conditions outside weren’t as good as usual, I took more images inside. The image and quote below are from an exhibit at MOMA (Museum of Modern Art). The first sentence made me think of the principle of unity. Do you sense how all the parts of a good picture are involved with each other, not just placed side by side? Art is a creation for the eye and can only be hinted at with words. John Baldessari, What Is Painting (1966–68) The vase below is from the Qing Dynasty and something it’s simplicity and minimal aesthetic grabbed me. We walked past it quickly on the way to an exhibit, but I had to go back after and grab a picture. Typography I came across a few typographic photo opps. First was a Gutenberg Bible in the Public Library. Second was this Hebrew table in the Metropolitan Museum of Art and finally is this poster by Jan Tschichold. It’s one I often come across and I can’t remember if I’ve ever included it in a post here. It was definitely cool to see the real thing. Lego The last exhibit we saw was Nathan Sawaya’s Art of the Brick. I’m sure many of you have come across images of some of his lego creations, probably the first image below. There were many more pieces than I expected. Some lego reproductions of famous works of art from Michelangelo’s statue if David and God touching Man from the Sistine Chapel to Munch’s The Scream. There were reproductions of the Parthenon and one of the statues from Easter Island. Some of what I saw you can see below. I was most impressed by the lego T-Rex, though my image doesn’t do it justice. The lighting left a green cast on the image and it’s hard to take the whole thing in, but hopefully you get the idea. I think 80,000 or so lego pieces were used in its creation. What struck me about the exhibit (aside from always thinking any lego creation about the coolest thing there is) was how anything can be used to create art. Curves are created with rectangular blocks. A few different colored blocks can be used to create dramatic lighting effects. And most importantly if you can envision it you can create it. Many of us grew up playing with lego blocks, but none of us saw the potential of lego as art until Nathan Sawaya showed everyone the way. Happy Thanksgiving I’ll leave you with a couple of images of Christmas trees. The first is from the Public Library and the second is from The Met. We didn’t get to see the big one at Rockefeller Center because of the rain. I assume it’s there, though probably not decorated yet, but we didn’t get to see it. Once again have a Happy Thanksgiving, a belated Happy Thanksgiving, or just a as good a Thursday as you can have. If you liked this post, consider buying my book Design Fundamentals The post Happy Thanksgiving — Images, Art, And Lego In New York appeared first on Vanseo Design.

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

Mobile Up, Widescreen Down, or Somewhere In-Between? - Vanseo Design

---

Mobile Up, Widescreen Down, or Somewhere In-Between? Posted: 25 Nov 2013 05:30 AM PST When designing and developing a responsive site should you begin with the small screen first and work your way up or would you do better to start big and work your way back down? Maybe one of the in-between breakpoints would make for a better place to start. Before responsive design things were easier. You chose the most common widescreen resolution and designed a fixed-width layout. As the years passed that fixed-width starting point grew. 960px became 1184px, but the general approach remained the same. You designed a single layout for a single resolution. That’s no longer true as the canvas we design for is unknowable. Responsive is Designing for a Series of End Points Visit a responsive website with your browser open to the dimensions of a smart phone and you’ll see a layout. Make your browser a little wider and the layout gets a little wider with it. Keep making your browser wider and the layout gets wider still, until at some point it changes more significantly. Likely another column appears or the navigation completely changes and moves. Keep making your browser wider and the same thing happens. At first the layout grows with the browser until at some point it again changes. Maybe a 3rd column is now present or that thing over there moved over here. This is typically how responsive layouts work. They grow and contract until growing or contracting any more will break them, at which point they change more significantly. Your site flexibly adapts between static points. At the very least there’s a smallest point and a largest point. There’s likely one or two more points in-between. Each of these points deserves some attention during design. You should know how the site will work at these “end points” before developing. Responsive design isn’t designing for a single static set of dimensions. It’s designing for several key sets of dimensions in a way that you can flexible get from one to the next. That still leaves the question of where to start. Do you still start with the widescreen display? Do you design the mobile view first? Is an in-between point the best place to start your design? Any approach can work, however I think mobile up is ultimately the best choice. Let me mention a few reasons why someone might choose the widescreen down approach and then offer why I prefer mobile up instead. Choosing to start somewhere in-between is really a combination of the two. Widescreen Down When I first began designing responsive sites, I was much more comfortable designing for widescreen than mobile and so hung on to the familiar while learning and exploring the new. It might also seem like there’s less decisions to make for mobile, given that the layout will be a single column where one thing falls below another. I suspect that for many people design is still what you do for a widescreen browser where there are multiple columns and multiple possibilities for where content can be located. It’s not really the case, but I think more than a few people hold it to be true. I’ve also found that while the design and development community is now familiar with the concept of responsive design, most of my clients aren’t. The majority are still focused on the widescreen and need to see the widescreen version of the design (specifically the one that works on their computer) before agreeing the design is what they want. Because some clients are focused on the widescreen version of the site, it’s tempting to design that first and only after receiving approval, do you work your way back down to mobile. Mobile Up Despite the above, I’d suggest that mobile up is the better approach. There are several reasons why it makes more to start at the minimum and then work your way up to the maximum. Mobile adds more constraints than widescreen — Hopefully we can agree that all devices should get the same content. There are certainly exceptions to this rule, but in general the same content should be available always even if it’s presented in different ways. The lack of space on mobile devices forces you to make hard choices about content and decide what should and shouldn’t be included. It’s much easier to make the decisions about content to include from the start than to build a layout to hold content that you later decide will no longer be part of the site. Once it’s in the design it’s harder to decide to remove it and once you’ve developed the site to hold it, it’s more work to remove it. Mobile still requires a specific html source order — When presenting a single column layout, elements on the screen will display in the same order they appear in the html source. In time flexbox and css grids will help solve the source order issue, but at the moment we’re locked into source order. Since, you’ll be using that same html source at widescreen, the css you use to present your wider design will be constrained by that source. If you build widescreen first, you’ll likely start with html that works best for widescreen. Later you may find that html doesn’t work well for the single column mobile layout, which will leave you reworking the structure. It’s easier to build up from a baseline — Widescreen first means putting everything in and then trying to find the bits and pieces to be removed. It’s more difficult to see what needs to change when there’s so much present. It’s much easier to make changes when there’s less code to sort through and change. The widescreen first approach will likely lead to more code duplication. It’s easier to keep your code DRYer if you start from the minimum and build up than to have everything there and remove some after. Working widescreen to mobile likely leads to more complex css in the end than working mobile to widescreen. Progressive enhancement — If you build mobile up you start by creating the minimum experience that works everywhere. In truth you could stop at that point and have a completed working website. More screen real estate is certainly not synonymous with more capabilities, but when the conversation is about layout only and the main limiting factor is space, then yes more screen real estate is more capable. Building from mobile up means first building the experience for all and then adding more for those screens more capable in terms of allowable space. Summary Designing responsively means designing a site for several key points based on device and conditions and then developing flexibly between those points. While a responsive site can be developed from either a mobile up or widescreen down approach, the former will usually lead to better results as mobile currently imposes more constraints. If you’ve never built a responsive site you might find it easier to start the first one from a widescreen down approach, in order to start from a familiar place, however as soon as possible move to the mobile up approach. If you liked this post, consider buying my book Design Fundamentals The post Mobile Up, Widescreen Down, or Somewhere In-Between? appeared first on Vanseo Design.

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

How Do You Prepare For Inevitable Change? - Vanseo Design

---

How Do You Prepare For Inevitable Change? Posted: 21 Nov 2013 05:30 AM PST When external forces impose a change you don’t like, what do you do? Do you fight and resist it? Do you adapt to it? How about when things aren’t changing. Do you prepare for change? Do you practice how you’ll deal with its arrival? Are you open to all the possibilities change brings? Note: This post includes an audio version. If you don’t see the audio above, Click here to listen. A few days ago as I write and a few weeks ago as you read, Apple released OS X Mavericks. I upgraded to the new OS as well as to the new iWork and iLife suites. As you may have heard a few features were removed from the apps in both suites. Most of the removed features weren’t things I relied on, however, Garageband did remove some podcasting tools that will make producing them a bit more difficult. I wasn’t even sure if I’d be able to continue using the new Garageband at first, but I accepted the change and found a way to accomplish what I needed to do. While it took a couple of hours to figure out a new workflow, the new way of doing is hardly difficult and in the end will add a only few minutes extra work for every podcast I produce. I share my Garageband woes to highlight something obvious. Things change. The tools we use change. Technology changes. Processes change. Business models change. Projects and clients come and go. Change is really the only constant we can rely on in life and the universe. The question isn’t whether or not things will change, but rather how do we deal with the inevitable change in everything. Embrace Change Instead of Resisting it Change can be driven by either external or internal forces and like everything else, comes with its own set of pros and cons. When it’s forced on us from outside it can be difficult, even painful, and we sometimes fight to restore the old order. Even internal change can sometimes feel less like a choice and more something we do out of desperation when life or business isn’t working as we’d like. On the positive side a change forced on us can open our eyes to things we hadn’t been aware existed or didn’t realize we’d enjoy so much. Internal change can come from somewhere other than desperation and come about simply as a desire to grow and expand beyond comfort zones. Like it or not, change is always happening and there’s little you can do to prevent it. It’s certainly easier to deal with when you make the decision to change, instead of having it forced on you. When you embrace change it’s easier to deal with and it places change under your control. You get to direct it when you make decisions about what to change. You can even learn to identify change that’s likely to be forced on you and prepare for its arrival by changing before you have to. The Rapid Pace of Technological Change We work in an industry where rapid change is the norm and if you’re going to survive and grow to become a better web designer, you need to adapt and grow with the changes around you. If you don’t embrace change in the industry, the industry will leave you behind. I’m still amazed when I receive comments on posts where I’ve compared css based layouts and table layouts. I have a hard time seeing how anyone who’s worked with both would choose the latter, but regardless of whether or not you agree, you have to accept the industry has moved on. Technology for web design and development evolves so from the css based approach, not the table based approached. Responsive design for example is difficult, if not impossible, with a table based layout. Compare how you design and develop sites now to how you designed and developed them a few years ago. You should see a lot of differences in your process and in the code you write. If you don’t see any difference, you might want to rethink your process. It’s not just our layouts that should be flexible and adapt in the new responsive landscape. We should be flexible and adapt as well. Change is inevitable. Learn to embrace and direct it. How to Make Change Work for You The more difficult changes to deal with are those forced on us without our being able to prepare. They disrupt the familiar and our minds are less focused on what we should do and more on what we no longer can do. The simple answer to not letting change control you is to not wait for it to happen, but rather direct its course. Be in a constant state of growth and consistently disrupt your own routines and comfort zones. Make small changes constantly Make large, wholesale changes occasionally Choose when the change should happen Change what you most need to improve Don’t wait for change to happen. Embrace that it will happen and train yourself to be open to it. Never get so locked in to one way of thinking or doing that you fail to see the possibilities and opportunities change brings. If you find yourself locked into a single train of thought, force yourself into a new train of thought just for the sake of change. Summary Like most people I still fight change at times. You should have seen me cursing out Apple for removing the nice and easy way I exported .mp3 files from Garageband. However, I’ve learned over the years, that there’s generally more good from change than bad. It might be painful the moment it comes, but it usually leads you to learn new things, see things in a different way, expand who you are, and in general grow to become a better you. For that good to come you need to embrace the change. Fighting the inevitable does no good. In the long run it’s easier to flow with the river than to waste energy swimming against it. Some change disrupts the familiar and makes your life more difficult for a time, but if you learn to flow with the inevitable you’ll find new becomes familiar once again. If from time to time you throw yourself into something new just because, you’ll find yourself better able to adapt to those changes inevitably forced on you. he not busy being born is busy dying —Bob Dylan If you liked this post, consider buying my book Design Fundamentals The post How Do You Prepare For Inevitable Change? appeared first on Vanseo Design. This posting includes an audio/video/photo media file: Download Now

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

Content Choreography — Why Our Float Based Approach To Layout Should Evolve - Vanseo Design

---

Content Choreography — Why Our Float Based Approach To Layout Should Evolve Posted: 18 Nov 2013 05:30 AM PST The easiest way to rearrange a design’s layout for different devices and conditions is simply to drop one column below another when space no longer allows them to sit side by side. It may be easiest, but it’s hardly the best approach. Today I want to look at a major consideration of responsive design, one that I think is going to drive all our thoughts about layout for several years to come. It’s something Trent Walton first called attention to a couple of years ago with a post on content choreography. It’s an issue I ran into around the same time when working on the current design of this site. And it’s something I wrote about for Smashing Magazine earlier this year. Column Drops aren’t Enough The problem with dropping columns is it’s a nuclear response done for our convenience and not our visitors benefit. If something is important enough to display at the top of the page when the browser is wide enough, why do we drop it far down the page, when the browser is narrower? Has it suddenly taken on less importance than all the content above it? Not likely. A better approach is to rearrange all the different blocks of content so that the most important is always the most visible and the least important is always the least visible. Better is to maintain the same hierarchy on narrow screens and wide screens and that requires more fine-grained control than dropping one column in its entirety below another. There are two challenges to overcome if we want this fine-grained control. In single column layouts the order elements display is the order they’re written in the html source code. How can we get around this issue of source order being the same as display order It’s difficult, if not impossible, for elements inside one container to intermix with elements inside another container. How can we gain more granular control over the placement of elements? Source Order There really isn’t any way around the first problem at the moment, outside of writing complex Javascript to build your layout. It’s a constraint we have to accept a little while longer. A little while isn’t forever, though. Flexbox breaks the dependence on source order and after experimenting with them a little, css grids will do to the same. The former has pretty good browser support right now and should be ready for production in the not too distant future. The latter is less supported and it will be a bit longer before we’re using it regularly. Both will render the problem of source order meaningless in time. The solution to the source order problem, as well as several other development problems is patience. A bit longer and things like flexbox, css grids, css regions, and other technologies on the way will solve a lot of issues for us. Containers Restrict Movement The issue of intermixing elements inside containers doesn’t have a technical solution on the horizon and it may never have one. The solution is really more about us rethinking our use of containers in html. rethinking our approach to html containers and using less of them is the fundamental challenge we're going to face as we create responsive layouts over the next few years By definition containers, contain. We wrap blocks of content in containers, because containers make developing layouts easier. It’s much easier to float a container that holds several blocks than it is to float each of the blocks individually. The latter can be done, but it usually leads to more and more complex css. The downside is what’s inside one container, can’t easily jump into another container and reflow with the content there. In fact, we can only make it appear content in one container has moved to another through complicated css. It takes something like Javascript to actually remove something from one container and place it in another. What we want is to be able to rearrange smaller blocks of content independently of each other. The ideal is to be able to place content anywhere in a design based on the device and conditions being used to access it. And then be able to place it somewhere else for a different device and under a different set of conditions However, in wrapping containers around multiple blocks, we remove the independence between the blocks. We make things less modular and less flexible when we add more containers. Containers giveth and they taketh away. They make it easier for us to develop a layout, but they become restrictive when the layout needs to change. A different layout tends to want a new set of containers. The solution to the container issue is to rethink our use of html containers, mainly with an eye toward using less of them. Breaking Free from Containers This idea of rethinking our approach to html containers and using less of them is the fundamental challenge we're going to face as we create responsive layouts over the next few years. Switching from absolute to relative measurements is easy. Determining when best to set a breakpoint is a matter of having the experience of few responsive sites behind you. Presenting flexible media, while difficult today, will get it’s technical solution before too long. Deciding which blocks of content need to reflow and how they can be reflowed is what design is going to be about. The decisions will change from one design to the next based on content priority and more and more of our time during design will be to resolve this question. This is the real flexibility we need to embrace as responsive web designers; the flexibility to rearrange blocks of content based on the content and not because technology makes it easy to rearrange them in a certain way. It will be difficult because we’ve come to rely on containing things in columns that we float left and right. Our present calls for containers. Our future calls for breaking free from them. Fewer containers will make development with floats more difficult so we should start thinking of new approaches. On the bright side, both flexbox and css grids will help as each reduces the reliance on floats. Each still places content in containers, but fewer of those containers are required to achieve the desired layout. However, with or without flexbox and css grids we’re going to have to rethink how we design and develop layouts. Greater consideration is going to have to go into managing more small blocks instead of a small handful of large ones. Given the current practice of float driven layouts. More containers lead to less flexible layouts that are easier to develop Less containers lead to more flexible layouts that are mare challenging to develop How we develop responsive layouts is going to be how we think about our html structure. Responsive design calls for more flexibility and modularity, but the way we’ve been structuring html is far less modular than we sometimes realize. We should be moving toward fewer html containers, which likely means something other than floats to drive layout development. If you liked this post, consider buying my book Design Fundamentals The post Content Choreography — Why Our Float Based Approach To Layout Should Evolve appeared first on Vanseo Design.

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

Should Designers Code? - Vanseo Design

---

Should Designers Code? Posted: 14 Nov 2013 05:30 AM PST Every industry has debates where people on either side hold rigidly to a point of view without really thinking through the issue. The world of web design is no exception and one of the debates we seem to argue about is whether or not web designers need to code to be effective web designers. Note: This post includes an audio version. If you don’t see the audio above, Click here to listen. I’ve said several times in the past that a word like need is too absolute. There is little you need to do. That’s the problem with this debate. The question isn’t whether or not web designers need to code, but rather should designers code, a subtle yet important distinction. A Lesson from Vincent van Gogh Awhile back I mentioned that I was rereading the letters of Vincent van Gogh. A few days ago I came across a passage in one of his letters that applies to this conversation of web designers and coding. Lately I have been working with printers ink, which is diluted with turpentine and applied with a brush. It gives very deep tones of black. Diluted with some Chinese white, it also gives good grays. By adding more or less turpentine, one can even wash it in very thinly. I think it will give good results on the paper Buhot gave you. Similar words to the above come up again and again in Vincent’s letters and in fact the above isn’t necessarily the best example of Van Gogh talking about the materials he used. It’s simply a recent example I came across. Notice the different materials Vincent mentions. Ink — Printers black and Chinese white Turpentine — As something to modify the output of the ink Brush — As the tool to apply the ink Paper — As the material which will hold the ink and render the finished work The passage isn’t about painting in the sense of how to compose a picture or which colors work well with others. It’s about the materials used, because the materials contribute to the finished work. While Van Gogh was an artist, it’s not hard to see how this applies to designers as well. Industrial designers need to become familiar with materials, because material and final product are so connected to each other. Graphic designers seek to understand materials, because the materials greatly influence the finished design, even if not as intertwined as with industrial design. Print designers consider ink and paper and they look beyond both. They look to cardboard, wood, vellum, and any other material that can color can be affixed to. They also look deeper at the paper to see what it can do beyond hold ink. The materials used to render designs can and will affect the resulting design. It makes sense to understand what you can about the materials you use daily and also explore materials you don’t commonly use. It gives you greater control over your finished work and it opens up new ways to explore and be creative. The Materials of Web Design Regardless of what kind of design you practice, materials play an important part in your finished design. Understanding the properties of ink and paper are no different than being practiced with a certain brush stroke, or understanding how effective use of visual weight creates hierarchy in a design. Two important materials web designers work with are code and browsers. They’re our ink and paper. Regardless of how much or little you know of them, anything you design is going to ultimately live in a browser and the browser is going to display your design based on what code is written and how it’s written. Do you need to know how to code or how a browser works to organize content, choose type and colors, or create an aesthetic for a site? Of course not. You don’t need to know either. However, the more you understand either or both, the more you can understand how your finished product will work and look. Web designers should spend time learning how to code for the same reasons they spend time learning how to use a graphic editor or learning what various shapes communicate and the role space plays in organizing information. You should spend time learning these things, because the learning will make you a better web designer, the same way understanding when to use a .jpg and when to use a .png makes you a better web designer. There are many more things beyond html and css that influence the finished design of a site. Things like gzip, DNS lookups, network connectivity, and latency. You don’t have to be an expert in all these things. I barely know what some of them are beyond having heard the term. You don’t need to know them, but as they affect how visitors are going to experience your design, the more you know about them, the better a designer you’ll be. Being able to code and understanding how browsers will render your code is no different for web designers than a print designer seeking to understand how a certain kind of paper will absorb a certain type of ink. It’s no different than Vincent van Gogh seeking to understand how he could alter and control the value of printer’s ink, by mixing it with turpentine. Do you need to code in order to be a web designer? Of course not. You don’t need to do much of anything. Should you code in order to be a web designer? Absolutely, since it will only make you a better web designer. If you liked this post, consider buying my book Design Fundamentals The post Should Designers Code? appeared first on Vanseo Design. This posting includes an audio/video/photo media file: Download Now

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