    
|
When I started learning to program back in February 2012 in order to build Uncover, I simply wanted to be able to see my ideas through to a solid prototype that customers could use. Nothing else mattered. I’d watch tutorials, read books, practice exercises, deploy code, fail and repeat–until I collapsed on my keyboard. Every day I’d wake up with a strong sense of accomplishment.
But no matter how much progress I made, I still knew I’d need to find a talented technical co-founder to work with. I’ve been around the block enough times to know that a year of programming wouldn’t make me a CTO. But what I couldn’t have anticipated was that learning to program up to the level I’ve achieved would make finding a technical co-founder ten times easier. Sure, it’s sort of a kick in the face knowing that one day, with any product success, you’ll have to pass the lead to someone more capable than you. But again, the huge consolation is that it’s a lot easier to find someone once you’ve learned to code.
For me, with a prototype in September 2012 and happy customers already in place, that time had come.
Because I’ve asked Mike (my Uncover co-founder) to be candid about it, I can say without a doubt that we’d never have teamed up if I hadn’t spent 2012 learning to code. Mike and I had known each other for five years before we decided to work together. It wasn’t until I was months into learning to code, when he saw my dedication and saw that I’d successfully built a prototype, that he began to entertain the idea.
Even during the first few months of coding, I’d badger Mike about working together over frequent afternoon coffees, but he’d shrug off the idea. He wasn’t looking to be someone’s code monkey. He wanted to work with someone who understood programming, who could contribute, and who had proven that he really wanted to push himself ahead technically. The person Mike would be willing to work with had to build something first.
For Mike it was more than me being able to contribute code to our product. It was about the psychological connection we’d have. There’s a special bond that exists between developers. People who can build product look at what’s built in a different way. “You can code? Welcome to the club.”
Mike welcomed me. He then pushed me. He taught me. He made me a better developer than I could ever have been on my own. And ultimately he agreed to join Uncover as a co-founder because I had proven myself and managed to get into the club.
The post How Learning to Program Got Me A Technical Co-Founder appeared first on Treehouse Blog.
]]>The following is a guest post by Marcel Shields. Marcel in a difficult place where he needed to change the image on a page but didn't have access to the HTML. Rare, but I'm sure we've all be in weird situations like this. He explains how he managed to replace that image without needing to access the HTML or JavaScript. Also turns out to be a pretty good way to replace anything with an image.
I just wanted to share something I found really cool about using CSS box-sizing. Chris wrote a really good introduction a few years back if you're not familiar with the property. It makes things a lot more sane when thinking about layout. People love it so much, they put it on everything like hot sauce. I wanted to share how I found it useful as (yet) another image replacement technique.
A few days ago at work, I was asked to replace an <img> on our site with another image hosted elsewhere. Simple right? But the catch was I would not be able to replace the markup as it was already deployed to production, but could inject CSS or JS through our CMS. For whichever technology I chose, it would be inserted on all site pages. I only needed on one specific page, and the attributes of parent containers were non-specific to the desired page.
<head>
<title>Really Cool Page</title>
</head>
<body>
<!-- .header would be across site on other pages with different children, so no background image adding -->
<div class="header">
<img class="banner" src="http://notrealdomain1.com/banner.png">
</div>
</body>This is simple to do with JavaScript, but I wanted to see if there was another, even simpler, way. After a few iterations in Chrome Dev Tools, I thought to use the box-sizing property to keep dimensions strict, add the new image as a background image, and just push the inline image out of the way with padding and see what happened.
/* All in one selector */
.banner {
display: block;
-moz-box-sizing: border-box;
box-sizing: border-box;
background: url(http://notrealdomain2.com/newbanner.png) no-repeat;
width: 180px; /* Width of new image */
height: 236px; /* Height of new image */
padding-left: 180px; /* Equal to width of new image */
}It worked beautifully. Here's what's cool:
<img> or <hr>
display: none or other propertiesThat last point seemed important, as it works really well for text replacement too without any adjustment. Check it out!
Check out this Pen!
Replace the Image in an <img> with CSS is a post from CSS-Tricks
]]>|
|
|
|
|
|
|
|
Up for grabs in this week’s giveaway are three 30-day subscriptions to Depositphotos — one of the most popular sites for downloading royalty-free files online. The subscriptions being given away are usually worth $99 each. The subscriptions will allow the winners to download up to 300 royalty-free stock photos, illustrations, videos, vector art, etc. Read on to see how you can be one of our lucky winners!
Depositphotos is a creative online platform that gives its users an opportunity to buy and sell high-quality stock photos, vector images, and videos.
They have various subscription options to make sure that you’ll find one that’s friendly to your budget.
Established in 2009, Depositphotos is a continually growing company that serves customers from 192 countries. They are proud to provide their customers with support in 14 languages. The agency’s headquarters is located in Florida, USA.
Depositphotos is currently sponsoring bloggers and site owners by giving them free Depositphotos subscriptions.
Read more about their program for bloggers and site owners on the Depositphotos website.
For a chance to win a 30-day free subscription to Depositphotos, simply follow these instructions:
1) Go to the their royalty-free stock library: http://depositphotos.com/category/
2) Find a stock file that you really like
3) In the comments section at the bottom of this post:
This giveaway ends on Monday, May 27, 2013 after which the comments section on this post will be closed and you will no longer be able to leave a comment. Please leave a valid email address when filling out the comment form so that we can contact you if you’ve won. Please only comment once. The winners will be randomly selected using the same method as previous Six Revisions giveaways. The winners will be announced on a separate post and you’re advised to subscribe to our RSS feed so that you can be quickly notified when the winners announcement post has been published. Please note that comments are moderated and so your comment may not show up right away. Please also note that comments that do not follow the instructions on how to participate (described above) may not be published, or may be removed later on.
Jacob Gube is the Founder and Chief Editor of Six Revisions. He’s also a web developer/designer who specializes in front-end development (JavaScript, HTML, CSS) and also a book author. If you’d like to connect with him, head on over to the contact page and follow him on Twitter: @sixrevisions.
Recently, Condé Nast Digital undertook a complete redesign of the articles published on wired.co.uk. The aim was to provide a more content-first and immersive experience. These aims were established after research by our Information Architect.
We started on the path of fulfilling those aims over a year ago with the redesign of the GQ.co.uk articles and the introduction of what we call the ‘StickyScrollRead’ component, which allowed the editors to embed media that would be pulled out of the body copy at screen widths wider that 1000px and pinned on screen. That meant the user could continue to read the article and still refer to the peice of media that the copy was about. This proved to be a much more immersive experience and allowed the body copy more room to breath.
We wanted the Wired article templates to maintain the SSR functionality that had worked so well on GQ but we had also learnt a lot since the GQ designs that we could incorporate into Wired. Design process wise, we had also evolved a lot more too since the GQ articles were designed.
The templates for the GQ articles were designed entirely with Photoshop, with every different article variant (long form article, short form article, straight to gallery etc..) and every article template with a different embed (short form article with image embed, short form article with video…) being mocked up as a PSD. We ended up with 20 – 30 PSD’s and a wall of printouts that covered the office! It was time consuming, tedious and did not represent the final product as we would ‘tweak’ things during the development process.
The proposed concept for the Wired article designs was more in depth and advanced than its GQ counterpart and the thought of mocking up 50 – 60 Photoshop files was enough for us to put down our PS lasso tool and explore more accurate and efficient methods of communicating our designs to the development team.
The GQ articles that preceded the Wired redesign.
As many of our projects do, we started by looking at how we could represent the brand’s values through its typography. We looked through the printed magazine and identified styles that they use to tell different stories, colors they had used as well as styles for highlighting text and captions.
We then started to experiment with different type combinations, colors and font sizes through Typecast, creating a complete initial style guide for all headings, paragraphs and pull quotes as well as experimenting with side by side comparisons. This would prove to be the groundwork for our typography which we would return to later.
Building a style guide in Typecast.
The style guide implemented.
We picked an article from the print magazine and found the equivalent article on wired.co.uk. They were exactly the same story but where the magazine article had images of varying sizes, pull quotes spanning columns with the paragraph text wrapping around it and ample additions of white space, the online equivalent had a lead image above one long area of text surrounded by the site housing, shouting at the user to view something else.
The old Wired article design.
Wired magazine is well known for it’s innovative and bespoke layouts, for which it has won many awards. We wanted to try and replicate the magazine style layouts, with bits cutting into the body copy and not have all the copy area feel so regimented. We knew that the SSR component splits the page into 2 columns, one for the article body and one for the media embeds that get pulled out and pinned but we didn’t want the embeds to feel completely detached from the paragraph text.
We began to create the same article, using the same copy and images from the website to create a basic version of the SSR template using CodePen. The goal was to experiment with placing full width, keep in line and in content media within the flow of the article to create a more visually striking and engaging layout. Since designing the GQ article pages we had decided that it would be a more natural reading experience to have the copy on the left and the media in the right column so we switched them around and we also wanted to incorporate the standard ad units such as the double sky and MPU’s within the body copy, rather than give the adverts their own column (like on GQ) that would be redundant when there were no ads or when the ads had scrolled away.
Building in Codepen.
In the first prototype the article led with a huge, full width landscape image which had much more impact and gave the sense of a magazine feature article. One of my favourite evolutions from the GQ templates was the introduction of the all mighty full-width image. GQ’s template enabled the editors to add ‘Pulled-to-side’ portrait and landscape images but they could sometimes lose their presence as the user’s screen got narrower and the images shrunk and the full width image was our solution.
The typography styles created in Typecast had not been used yet but there were basic styles assigned to the paragraph, intro text and quotes to help get a sense of hierarchy.
The SSR had also not been implemented but a column had been created with pull to side images which helped us to experiment with what width to set the pull to side column in relation to the page and basic double sky and MPU units were added to the body copy to see if they would disturb the flow of the text.
As a first draft, this approach proved far more useful than us experimenting with the same content via Photoshop. This not only allowed us to make some basic layout decisions quickly and iteratively but we could also use it as a base from which the developers could build on to add further functionality to and that’s exactly what they did.
Version 1.
The CodePen proof of concept was passed onto the development team and they added the SSR functionality (so the pulled to side images actually pinned to the screen) as well as allowing us to change the positioning of a piece of media by changing its class before handing it back to the design team for styling.
At this point, we started to style the article with the font styles that we had previously created in Typecast by simply exporting the CSS directly from the web app. We could now also start experimenting more with different ways to embed content and see what worked well at different widths and for different stories. For example, leading with a full width portrait image was a bad idea as there would be an abundance of white space around the title and would also push the first paragraph too far down the page. We found that the best combinations seemed to be to lead with a pulled to side image and maybe a keep in line landscape as they had the least effect on the flow of the text. We also worked on optimizing the body copy for the most comfortable reading experience by controlling the max-width of the paragraph copy. Instead of adding more padding between the paragraph text and the pulled to side media, we indented the body copy so that the copy was as central on the screen as possible and it also allowed keep in line images to bleed off the screen much like a print layout might do.
Prototyping version 2.
This collaborative and agile prototyping method helped us to really make informed decisions quickly as we could easily test our designs on any device, screen width or browser and make amends with minimal fuss. We worked with real content as much as possible to make sure that we were not forgetting to style a certain rare class that gets added to only a few paragraphs — I’m looking at you .p1 — that we may otherwise have missed until later in development. We also created multiple article types using the same template to see how it worked when there was just 1 image and some short copy or if it was a review article.
Although we always knew that our CodePen templates were only going to be a proof of concept, we really tried to go into as much detail and make as many informed decisions about the design and layout as early on as possible.
Once we were happy with the basic style and structure of the template, the developers transferred the code into their own coding environment, splitting up the CSS for each media embed into it’s own SASS file so the design team could easily access and change the CSS for just the ‘blob’ — which is what we ended up calling any add-ons that you could embed within an article… eg. images, video, reviews…etc — that we wanted to edit.
This was a huge help as by the time the dev’s had done their stuff and hooked it all up to the back end, the code was too complicated for any of us designers to understand and locate the parts that we wanted to change. This approach was also useful when styling new blobs, like the gallery thumbnails, read next or review ratings, as we would just create a new SCSS file with all the styles for just that individual blob, which made it far easier to update and maintain.
The ability to access and edit the CSS was a huge help to us designers. It was the first time that we had moved away from the ‘design in Photoshop – deliver PSDs – developers code – designers review’, method of creating a website and it meant that we were able to really fine tune the smallest aspects of our designs.
In the past, using the old methods, we may of launched the Wired articles at this stage (fully functional with some design tweaks which can be made after launch) but as us designers now had access to the CSS, we were able to spend the last few days adding a few subtle touches that would improve the experience. We added little ‘Enlarge’ icons on the corner of the images to let the user know that by clicking on any of them, you could open them as a full width, gallery image. We user tested articles on different devices to get the optimum body copy width for the best reading experience as well as spent more time fine-tuning the text links, quote styles and image captions, all small details that would together make a big difference.
This was a far more collaborative project than any other I had previously worked on with designers, information architects, project managers, developers and editors all working together at different stages of the project; adding their bit to a prototype that was constantly growing and developing into the product that it is today.
The final, fully responsive article design.
Not spending time designing all the styles, layouts and variations at different break points beforehand, meant that we could in a way, design by development. We wouldn’t wait until something was perfect to build it but instead just built something and worked on getting it perfect. This did mean that there were days where we would measure once and cut ten times but it also allowed for constant testing, development and more importantly, discussion on improvements which helped keep everyone engaged and involved with the project.
We are constantly reviewing and improving the build but we are also very proud of what we have managed to deliver in a pretty short period of time. The Wired articles not only represent beautiful, print style layout at any screen width and on any device but also a shift in the way we at Condé Nast Digital work as a team.
What do you think of the wired.co.uk article pages? How does Condé Nast Digital’s design process compare with your own? Let us know in the comments.
| Magnolia: 150+ Professional Infographic Elements – only $9! |
 |
Recently, Condé Nast Digital undertook a complete redesign of the articles published on wired.co.uk. The aim was to provide a more content-first and immersive experience. These aims were established after research by our Information Architect.
We started on the path of fulfilling those aims over a year ago with the redesign of the GQ.co.uk articles and the introduction of what we call the ‘StickyScrollRead’ component, which allowed the editors to embed media that would be pulled out of the body copy at screen widths wider that 1000px and pinned on screen. That meant the user could continue to read the article and still refer to the peice of media that the copy was about. This proved to be a much more immersive experience and allowed the body copy more room to breath.
We wanted the Wired article templates to maintain the SSR functionality that had worked so well on GQ but we had also learnt a lot since the GQ designs that we could incorporate into Wired. Design process wise, we had also evolved a lot more too since the GQ articles were designed.
The templates for the GQ articles were designed entirely with Photoshop, with every different article variant (long form article, short form article, straight to gallery etc..) and every article template with a different embed (short form article with image embed, short form article with video…) being mocked up as a PSD. We ended up with 20 – 30 PSD’s and a wall of printouts that covered the office! It was time consuming, tedious and did not represent the final product as we would ‘tweak’ things during the development process.
The proposed concept for the Wired article designs was more in depth and advanced than its GQ counterpart and the thought of mocking up 50 – 60 Photoshop files was enough for us to put down our PS lasso tool and explore more accurate and efficient methods of communicating our designs to the development team.
The GQ articles that preceded the Wired redesign.
As many of our projects do, we started by looking at how we could represent the brand’s values through its typography. We looked through the printed magazine and identified styles that they use to tell different stories, colors they had used as well as styles for highlighting text and captions.
We then started to experiment with different type combinations, colors and font sizes through Typecast, creating a complete initial style guide for all headings, paragraphs and pull quotes as well as experimenting with side by side comparisons. This would prove to be the groundwork for our typography which we would return to later.
Building a style guide in Typecast.
The style guide implemented.
We picked an article from the print magazine and found the equivalent article on wired.co.uk. They were exactly the same story but where the magazine article had images of varying sizes, pull quotes spanning columns with the paragraph text wrapping around it and ample additions of white space, the online equivalent had a lead image above one long area of text surrounded by the site housing, shouting at the user to view something else.
The old Wired article design.
Wired magazine is well known for it’s innovative and bespoke layouts, for which it has won many awards. We wanted to try and replicate the magazine style layouts, with bits cutting into the body copy and not have all the copy area feel so regimented. We knew that the SSR component splits the page into 2 columns, one for the article body and one for the media embeds that get pulled out and pinned but we didn’t want the embeds to feel completely detached from the paragraph text.
We began to create the same article, using the same copy and images from the website to create a basic version of the SSR template using CodePen. The goal was to experiment with placing full width, keep in line and in content media within the flow of the article to create a more visually striking and engaging layout. Since designing the GQ article pages we had decided that it would be a more natural reading experience to have the copy on the left and the media in the right column so we switched them around and we also wanted to incorporate the standard ad units such as the double sky and MPU’s within the body copy, rather than give the adverts their own column (like on GQ) that would be redundant when there were no ads or when the ads had scrolled away.
Building in Codepen.
In the first prototype the article led with a huge, full width landscape image which had much more impact and gave the sense of a magazine feature article. One of my favourite evolutions from the GQ templates was the introduction of the all mighty full-width image. GQ’s template enabled the editors to add ‘Pulled-to-side’ portrait and landscape images but they could sometimes lose their presence as the user’s screen got narrower and the images shrunk and the full width image was our solution.
The typography styles created in Typecast had not been used yet but there were basic styles assigned to the paragraph, intro text and quotes to help get a sense of hierarchy.
The SSR had also not been implemented but a column had been created with pull to side images which helped us to experiment with what width to set the pull to side column in relation to the page and basic double sky and MPU units were added to the body copy to see if they would disturb the flow of the text.
As a first draft, this approach proved far more useful than us experimenting with the same content via Photoshop. This not only allowed us to make some basic layout decisions quickly and iteratively but we could also use it as a base from which the developers could build on to add further functionality to and that’s exactly what they did.
Version 1.
The CodePen proof of concept was passed onto the development team and they added the SSR functionality (so the pulled to side images actually pinned to the screen) as well as allowing us to change the positioning of a piece of media by changing its class before handing it back to the design team for styling.
At this point, we started to style the article with the font styles that we had previously created in Typecast by simply exporting the CSS directly from the web app. We could now also start experimenting more with different ways to embed content and see what worked well at different widths and for different stories. For example, leading with a full width portrait image was a bad idea as there would be an abundance of white space around the title and would also push the first paragraph too far down the page. We found that the best combinations seemed to be to lead with a pulled to side image and maybe a keep in line landscape as they had the least effect on the flow of the text. We also worked on optimizing the body copy for the most comfortable reading experience by controlling the max-width of the paragraph copy. Instead of adding more padding between the paragraph text and the pulled to side media, we indented the body copy so that the copy was as central on the screen as possible and it also allowed keep in line images to bleed off the screen much like a print layout might do.
Prototyping version 2.
This collaborative and agile prototyping method helped us to really make informed decisions quickly as we could easily test our designs on any device, screen width or browser and make amends with minimal fuss. We worked with real content as much as possible to make sure that we were not forgetting to style a certain rare class that gets added to only a few paragraphs — I’m looking at you .p1 — that we may otherwise have missed until later in development. We also created multiple article types using the same template to see how it worked when there was just 1 image and some short copy or if it was a review article.
Although we always knew that our CodePen templates were only going to be a proof of concept, we really tried to go into as much detail and make as many informed decisions about the design and layout as early on as possible.
Once we were happy with the basic style and structure of the template, the developers transferred the code into their own coding environment, splitting up the CSS for each media embed into it’s own SASS file so the design team could easily access and change the CSS for just the ‘blob’ — which is what we ended up calling any add-ons that you could embed within an article… eg. images, video, reviews…etc — that we wanted to edit.
This was a huge help as by the time the dev’s had done their stuff and hooked it all up to the back end, the code was too complicated for any of us designers to understand and locate the parts that we wanted to change. This approach was also useful when styling new blobs, like the gallery thumbnails, read next or review ratings, as we would just create a new SCSS file with all the styles for just that individual blob, which made it far easier to update and maintain.
The ability to access and edit the CSS was a huge help to us designers. It was the first time that we had moved away from the ‘design in Photoshop – deliver PSDs – developers code – designers review’, method of creating a website and it meant that we were able to really fine tune the smallest aspects of our designs.
In the past, using the old methods, we may of launched the Wired articles at this stage (fully functional with some design tweaks which can be made after launch) but as us designers now had access to the CSS, we were able to spend the last few days adding a few subtle touches that would improve the experience. We added little ‘Enlarge’ icons on the corner of the images to let the user know that by clicking on any of them, you could open them as a full width, gallery image. We user tested articles on different devices to get the optimum body copy width for the best reading experience as well as spent more time fine-tuning the text links, quote styles and image captions, all small details that would together make a big difference.
This was a far more collaborative project than any other I had previously worked on with designers, information architects, project managers, developers and editors all working together at different stages of the project; adding their bit to a prototype that was constantly growing and developing into the product that it is today.
The final, fully responsive article design.
Not spending time designing all the styles, layouts and variations at different break points beforehand, meant that we could in a way, design by development. We wouldn’t wait until something was perfect to build it but instead just built something and worked on getting it perfect. This did mean that there were days where we would measure once and cut ten times but it also allowed for constant testing, development and more importantly, discussion on improvements which helped keep everyone engaged and involved with the project.
We are constantly reviewing and improving the build but we are also very proud of what we have managed to deliver in a pretty short period of time. The Wired articles not only represent beautiful, print style layout at any screen width and on any device but also a shift in the way we at Condé Nast Digital work as a team.
What do you think of the wired.co.uk article pages? How does Condé Nast Digital’s design process compare with your own? Let us know in the comments.
| Magnolia: 150+ Professional Infographic Elements – only $9! | |
|
|