Hey y’all! Welcome Miriam Suzanne. Miriam will be doing more writing around here soon, so we figured an interview would be a good way for you to get to know her first. She’s been working with the web for longer than I have, has created some pretty huge open source projects, and has a unique perspective on about everything. Let’s get to the chat!
Chris: How old school are you? Were you designing websites in tables for Netscape Navigator -3 and stuff? Or did you get into the web later?
Miriam: I built my first sites in the early 2000’s — so we were past Navigator 3 at that point. It was the height of the Netscape/IE browser wars, when sites all said “best viewed in” one or the other. CSS was just gaining real traction. I was taught to use tables in Dreamweaver, but I didn’t get excited about the web until I saw Eric Meyer’s CSS Edge site, and started coding by hand. I got my first job using tables on an insurance company website. I tried to rewrite their site in CSS, but they didn’t want it. I started freelancing right after that, and never used tables again.
I was slightly behind you I think. I don’t think I ever built a production site with tables, thankfully.
Kids these days. 😉
Speaking of Eric Meyer, I think I first met you when you were also going by Eric Meyer. We met at a conference, through your involvement with Sass and being the creator of Susy and such. I seem to remember you saying that both of you had to re-direct people to each other when they contacted the wrong one. But now you’ve changed your name! Was that just a part of a larger identity change?
Well, if you remember, it happened in two stages. I changed my last name in 2013 to break up that confusion.
I had a sense at the time that I should be changing more than that — but I wasn’t ready to deal with it.
I finally changed my first name and started to transition last year.
It would have been easier to do both at once, but… Can we call it an iterative process?
(Chris crawls under the table for making a joke so dumb it doesn’t even qualify as a dad joke.)
The final straw for breaking the Eric Meyer confusion involved a series of conferences. You got mixed up in that. 🙂
CSS Dev Conf gave you my hotel room after Eric Meyer had to cancel, and you took over as keynote.
(We were at The Stanley Hotel, which is known for being haunted and has freaky tunnels and ghost tours and stuff.)
They actually gave me a huge three-bedroom condo on the hill, 3 minutes away. I ended up hosting all the after-parties.
But earlier that year, I had a talk rejected at a digital-arts conference because the bio I sent them didn’t match the bio on Eric’s website. They basically accused me of lying.
Going backwards a little… your web career started with some insurance websites, then into freelance. And kinda staying in freelance? I know you and your siblings started OddBird almost a decade later.
I started building websites for my theater company. That’s why I learned web design in the first place. The insurance company mostly had me doing print design. They were so far behind the digital curve.
At one point my good-ol-boy boss called me into his office, probably because I was the youngest on staff, and said “We need a podcast. What’s a podcast?”
That was pretty much the atmosphere of the place.
I told him a podcast is like a radio show, but you have to go looking for it. The first thing you need is content that people really want. “Oh, I don’t think we have that.”
I took my first client when someone asked if I knew anyone who could build a website cheap. I teamed up with a Drupal-expert, and we built a few sites together. I quit my insurance job half way into our second client, moved to Denver, and hoped for the best. That was 2006-2007. Carl and I started working together in 2008, and Jonny joined in 2009. That’s when we came up with the name, and decided to make a company out of it.
Yeah, we have a team of seven now, and act like a legit company.
We’re mostly hired to build custom Django web-applications for mid-to-large companies. We’ll build their MVP, get them off the ground, and then hand it over to an internal team.
We do the full range of branding, content, architecture, design, code, and testing — integrated pretty tightly, because we have a small team.
Mozilla gave us our first big break in 2010, building their test-management system. I hear they are finally retiring that project next month.
There are plenty of agencies out there that do great work for clients. There are less that decide to build, open source, and maintain large software projects like y’all have. Were projects like Susy built for client needs? Or itch-scratchy? What’s the story there?
Susy didn’t come out of one particular client, but it did come out of our client work.
We wanted a consistent set of tools that we could take from one client to the next, without forcing every client into the same design patterns and layout techniques.
I was really inspired by the work Natalie Downe and Clearleft were doing, and modeled my approach on her CSS Systems talk.
It’s all about designing open, flexible systems instead of locking yourself into a particular library of CSS classes — a response to the existing grid frameworks back then, and a philosophy that matched my thinking perfectly.
But the math was repetitive and complex, until we found Chris Eppstein’s hour-long video introduction to Sass and Compass.
Susy was the first thing I built in Sass, and the whole reason we wanted Sass in the first place.
After I built a draft, Carl put it on GitHub. I didn’t know anything about open-source development at the time. He was the driver behind all of that, but I had to learn quickly.
Susy was one of the early Sass/Compass plugins, so Chris took a real interest and pushed me to improve it, and document it, and make it work for a wider audience. Susy wouldn’t be where it is without a lot of early help.
Hmmmm so it’s possible to have good ideas and build cool things and participate in open source and not know everything about everything?
It’s possible without knowing anything interesting at all!
Now we think of open-source as a core of our process. We use existing tools where we can, making client work faster and more reliable — and then we contribute back into open-source from our client work. It’s a cycle.
For most of our history, open-source work and client referrals have been our only real marketing — mostly coming through the Django community, where Carl is a core developer.
My Sass projects bring in a lot of traffic to our site, but it’s hard to say how much influence that has on actual contracts. I wonder if there’s a back-end/front-end difference there, or if it just comes down to project size.
We’re trying to be more intentional about our marketing now, but still building on what’s worked for us: being active in the community through open-source work, charitable giving, and sharing what we learn through writing and speaking.
I’m really interested in some of the new features that are coming to CSS, like
@supports, grid layouts, and custom properties (variables).
Grids and variables particularly excite me because they represent fundamental shifts in how CSS works:
- Grids shift how we think about “flow” in a document. All the previous layout techniques are 1-dimensional, relative to flow. Grids are two-dimensional, outside of the flow. I’m curious what that does to the ways we think about web design.
- Variables and custom properties break the long-held belief that CSS should be purely descriptive. Now CSS is becoming an extensible language, with programmatic power. Hopefully that means we’re not always waiting for the w3c and browser vendors to solve new problems for us, adding new properties to the language. I’m excited to see how that plays out.
I also get excited about components and patterns, which are popular now. People are trying to represent design patterns in code more efficiently and meaningfully, and that’s a good thing. The virtual DOM is a really interesting step — but I think there are a lot of details still to work out. Especially when it comes to balancing efficiency with accessibility and maintainability.
I think we can do better, and I think we will.
I’ve been looking at what worked and what didn’t in Sass, and wondering if those lessons can be applied to HTML templating languages…
It seems like you have plenty of interests outside tech. Music! Theater! Writing! And not just in a passive way, like you go see a band on Friday night. You are the band on Friday night.
(Before I even asked this question, we had to take a break in the conversation because she had to get ready for a gig that evening.)
I never expected to be a web developer. My training is in “devised ensemble theater” — a technical term roughly equivalent to “greenfield iterative web-development.” Instead of starting with a pre-written script, and using a waterfall process, you start with an idea and a team of collaborators — then iterate your way to a full production, using whatever media will get you there. I ran a theater company from 2001-2006, learning design in order to make our brand and marketing materials, and learning code in order to build our first website.
All the product-development skills translate pretty directly. Before long I had my first client, and things built from there. But I still see the art as a central part of what I do. I don’t have a theater any more, but I have several multimedia novels and a successful band called Teacup Gorilla. We just finished underscoring two live theater productions, and now we’re going to work on a music video. Your career doesn’t have to define you, or take over your life.
To me it’s all one thing. I like building experiences, using whatever tools are available. Building a show, or an album, or a grid system, or a web app — those are minor details.
Yeah, my first attempt at a novel turned into 600 pages of full-color images. It cost me over $100 to print a proof at Kinkos. No publisher would take on a first novel like that, so I started putting it online, and adding animations. I never got very far, but it’s still out there. Maybe I’ll go back and finish some day, or maybe I won’t. I decided to keep things simpler for the second novel.
Riding SideSaddle* was published last year by SpringGun Press. It’s a story written on 250 note cards — a collection of memories that can be shuffled and read in any order. But don’t let the “experimental” format fool you: it’s a fast read, and the story is easy to piece together.
It’s based loosely on the greek myth of Salmacis and Hermaphroditus, who are merged into one person by the gods. It becomes a reflection on gender, sexuality, and queer communities.
That was also harder to print than we expected, but we made it work. My next novel will be a book book. Let’s keep things simple. 🙂
I think I surprised a lot of people in my writing community when I started talking about “innovation budgets” and “user testing” for my novel. I’m pretty happy with the results, though. Glad I could bring my product-development experience into my art.
Well, users are smarter than we give them credit. I don’t think my audience would ever want a standard sunset painting — it sounds like you don’t either. When I test Susy, half the time I’m learning that my users need more complexity, and more power. I think it’s common for UX developers and artists both to underestimate their audience — and I think that leads to bad/boring design.
But user-testing also doesn’t mean you only do what users ask for. I started with my own goals, and what I wanted to communicate. Then I had to watch people interact with it, to see if I was on the right track.
I don’t think well-done user-testing should ever keep you from innovating. It should give you the freedom to experiment, and then see what’s working and what isn’t.
In this case, the cards worked — as long as I added character names to all or most of them. People were happy to read the story out of order, as long as they had that handle to hold on to.
In my mind it’s mostly about trusting users to tell you what’s not working. But never trust them to tell you what will work. That’s where innovation and experimentation come in.
To say that a bit differently: for both art and product development, you have to trust the users and you have to trust yourself. Your own communication/business/aesthetic needs are just as important as the user’s needs. But you only have a successful product if you can get the two lined up.
You also have to trust that users want to be surprised, and that’s not something they can ever tell you how to accomplish.
They can only tell you that they are bored with sunset paintings. 🙂
Well, I think we can wrap this up with a big ol Welcome Aboard! Everyone out there reading, stay tuned for upcoming writing by Miriam. Anything else you’d like to tell folks?
I’m looking forward to it! If anyone has any topic request for me, I’d love to hear them.