095: With Daniel Mall

01:02:12   Download

This week we were joined by super-designer Dan Mall. Dan currently runs Superfriend.ly, is a co-host of the Businessology podcast, and previously worked at Happy Cog and Big Spaceship.

We talked about (roughly in order):

News’n’Links’n’Drama:

  • 17:10 CSSOff #hotdrama: Dan made a PSD that was too good.

Q & A:

  • 33:02 In defense of AMPPS…
  • 34:45 Can you guys rant about the different scenarios on how and/or when and/or why to use javascript on text/typography?
  • 46:21 How much testing and compatibility is enough? Should we just stick to the big 5 browsers on desktops, Android browsers, Safari on mobile devices?
  • 51:48 I’ve been trying a couple of CSS/JS frameworks lately (Bourbon+Neat, Foundation) and I’m struggling to choose which better suits my purposes. What do you suggest? What frameworks/libraries do you guys use for your projects?

Sponsors:

Show Links:

  • deconai

    Thanks for answering my hot drama question, guys! To be clear: I loved how challenging Dan’s design was. I don’t think Dan’s REALLY evil, maybe more maniacal…lol

    Also, is this the Ryan Singer video Chris mentioned?

    Thanks again guys! Keep up the good work. 🙂

    • Yeah just saw this video last week, Really great to see this kind of process thinking I wish there was more of it.

      • deconai

        It’s offered up by Peep Code, and they apparently have a boat load of content like this at Plural Sight.

        • Yeah I saw that. PC was bought by Plural Site. Most of the other Play by Play videos like seem to be focused on backend programming.

          • deconai

            Hmmm…didn’t notice that. Sounds like this might be an excellent opportunity to development some content.

  • Jermbo Lawman

    I wanted to comment on your answer on question, “which frame work should i use” ( or something like that… the question starts at 51:48 )

    I have had this same question over the past few months now, if not year. While I have just gotten into a css preprocessor around that time and was trying to find the best and couldn’t find anything what would be exactly what I needed, or to much for what I needed. So, what I did is chose LESS as my preprocessor and took mixins from Bootstrap and LessHat and Preboot. My grid system is Skeleton, I really liked the way they named their columns and the fact they based things on pixels and not percents was really nice. Then took Bones for wordpress because I really liked they way the take out some bloat and added some security.

    So I have taken all of that, mushed them together and have fit those into what I work on, on a daily basis. I reduced the bloat by separating out the items into different files and only calling the ones in need with the less imports. And Bones acts as my parent theme in wordpress, and my child theme makes all the front end decisions. This has really helped me out since I used to start everything from scratch and re-inventing the wheel for every project, now I have my own “bootstrap” that is everything I need, be it super feature rich or just a grid system for simple landing pages.

    I have recently discovered your show, don’t know how I missed it since I am on css-tricks, um… all the time, and you guys make my commute to work better. Love the show guys, keep em coming!

  • Thank you for answering my question! (at 51:48)
    I thought that you receive a lot of question every day and I was absolutely surprised to hear it so soon.

    I’ve come to the same conclusion that I should compile my own grid and mixins library.

    But I want to clarify why I’m a bit anxious about modifying vendor dependencies, like foundation.

    I also work on a backend a lot and I learned in the beginning that if you need to overcome some unsuitable issue in the library and you’ve got 2 options: circumvent it in your own code, or modify library’s code – most of the time, the first choice is a better one.

    The second choice, as you said yourself, would break upgradability and your code would be hard to grasp by other programmers.

    This’s why occasional and justified monkey-patching in ruby is acceptable.

    Also, I tend to think that collective mind is better at programming than an individual. I don’t think that I’m smart enough to understand all the reasons behind some of the code. I may reckon that I don’t need some obscure function or module, but I could be wrong, because I didn’t have years of experience of dealing with the exact problem that this library or module is trying to solve. As a result, I may break it and spend the rest of the day trying to understand why it isn’t working as I need it.

    I’ve been in the similar situations before. And I was wrong 80% of the time. Now I alter the library’s code only I’m certain that I understand how it works, I tried to find an issue with the similar problem (it can give me the reasons why it wasn’t implemented yet and show me edge-cases that I haven’t thought of) and I’m sure that there’s no sane way around it.

    As a result, I’m trying to apply the same rules to my sass/css workflow and it doesn’t work as well as I hoped.

    One of the reasons is that I mostly don’t care how code in the ruby library looks like, as long as it works correctly.

    But I do care greatly how my final CSS looks like. So, it matters how an author implements features. Couple it with the fact that we’ve got an ocean of hacks and workarounds in css (like floats for grids) and it results in a ton of different approaches.

    The good part is that SASS/CSS libraries aren’t as complicated as ruby or python libraries. It means that it’s not that hard to write your own version of grids, forms or animations.

    But when you see Foundation or Bootstrap for the 1st time, it surely looks like all of your problems are over. It’s going to be straight road from now on. I thought that way, even despite the fact that I’ve been working with plain CSS for 2 years before.

    Also, as I’m plunging into the depths of SASS, I’m learning new ways to write styles and more importantly, think about them. I’m used to creating common classes like “.tile” or “.featured-item” and using them on different pages to style similar objects. But SASS gives me @extend that allows me to solve the same problem differently. And this breaking of familiar patterns messed up my mind. I know that I could gradually introduce myself to SASS, but once I learned the basics, it was impossible to stop.

    It’s got a bit long, but I hope I made myself clear.)

    • Jermbo Lawman

      I thought the point of your question was quite clear, as I have gone through the same situation. I’ve been a front end developer for +-8 years now and trying to break the old habits with the new OOCSS / SMACSS and / or preprocessors and / or CSS Frameworks, was at first a great thing in theory but I initially found it hard to add to my work flow. Now its all over my work, I realized I was doing some of those things in some degree before I heard those names. And now I am not sure how I got along with out it.

      “I tend to think that collective mind is better at programming than an individual” <- I agree 100% with that statement, I always prefer to work with a group than with myself alone. I feel a better project gets built with a collective mind than with just one, in most cases. Having said that, by creating a mosh of what the collective has built is the same as if they were working on the project with you. By getting the pieces you need and putting it into a format that you understand and can work with on a daily basis is, I feel, an overall goal of what each framework is trying to solve. If you can use their framework fully, cool, if you take a piece and add it to your project, thats cool to.

  • Kurt Meredith

    Chris, Thank you so much for mentioning my “Fading Away” animation in this podcast (28:25)! I really enjoyed trying my hand at this year’s CSSOff, and look forward to next year. Codepen Rocks!

    Dan, Your design was great. Despite any complaints you may have received, it was perfectly filled with obvious, and subtle, challenges. As I worked on my submission (which did not make the deadline :'( ) I kept wondering if you had added some elements as “trick questions” so-to-speak.

    Examples of my over-thinking:
    1) The text breaking out of the purple box seemed like an obvious test to see how folks would handle it.
    2) The upside-down head shots had me wondering if there would be a “judging penalty” if we did not use CSS transforms to rotate them.
    3) The “List style bullets” really had me over-thinking things. I felt certain that this was one of those “trick questions” and that if we did not use the bullet photos as the actual “bullets” in an unordered list we would have our wrists slapped with a ruler! (I can’t tell you how long I struggled with this! As far as I can tell, there is no way to make “bullets” layer behind their labels, which is what would have to happen in order to match your design. Obviously my over-thinking went a bit too far. 😉 )

    I am surprised that you received complaints about the PSD file! I used to be a professional digital pre-press guy before I got into web development. I was the one who would prepare a Graphic Designer’s files for printing. In my experience, Graphic Designers very rarely provided any support files–everything was lo-res, un-silo’d, off-color, gobbledy-gook that I had to work magic with to get it ready for production. The file you provided was exactly what I would have expected to receive and actually more than I would expect, because it was actually a _layered_ PSD file!

    Thanks to @therealmarklee for pointing me to this podcast!

    • chriscoyier

      High five for the pre-press history! Me too.

      • Kurt Meredith

        Very cool, Chris!

        Ya know, after I re-read my comment I realized that I might be both showing my age and doing Graphic Designers, past and present, an injustice. Back during my early pre-press days, Photoshop did not even HAVE layers, and even after it did, megabytes of RAM (no one even knew what a gigabyte was) weren’t as cheap or as easy to come by as they are in today’s computer systems. This meant that, in order to work speedily, designers pretty much had to work with lo-res “placeholder” images as they were doing their designs. That’s where we pre-press pros came in. We had the tools, the horsepower and the knowledge to take those designs and re-work them into something that could be used for high-quality printing.

        Nowadays (there I go showing my age again), designers have better tools, more powerful systems, and many of them are much more knowledgeable about setting up their designs for printing. Not to mention that you can now turn in a print job as a single PDF email attachment, rather than courier a Zip disk containing the native Quark XPress file, all supporting images, and copies of all fonts.

        The good-old-days? HA! Give me these great-new-days every time!

  • Thanks guys for the Open Source Design mention and link.