As more people become aware of SproutCore, there have been some common questions raised about who is actually using the framework and what are companies and individuals doing with it in order to make a successful product. I figured one way of trying to address those questions, and even have some fun with it, is to go directly to the people who have used SproutCore and let them speak for themselves through an interview — a SproutCore interview. Therefore, as an initial experiment, I roped in two colleagues of mine, Matt Grantham (@MattGrantham) and Ryan Mudryk (@ry), and let them discuss SproutCore from a web designers perspective. So without further ado, let’s get this first SproutCore interview started. Hope you all enjoy!
Frozen Canuck: Hi guys, and welcome to the first, of what I hope is many, SproutCore interview. Although I work with you two, perhaps I could get you both to introduce yourself to everyone.
Matt Grantham: Sure thing. My name is Matt Grantham and I’m the lead designer at Eloqua out of our Toronto office. My job is mainly focused on taking requirements from the project management team, different stakeholders within the organization, and essentially distilling those down into my end product which are high-fidelity mock-ups done in PhotoShop. I then pass those mock-ups on to Ryan for implementation.
Ryan Mudryk: Well, Matt pretty much described my role at Eloqua for me [laughs]. Anyway, my name is Ryan Mudryk and I’m a designer and front-end developer at Eloqua. For the most part, I spend my time taking the mock-ups that Matt produces and coding them into SproutCore.
FC: What do you see as being the main differences between designing a traditional website that web designers are familiar with and designing a SproutCore application?
MG: I’ll let Ryan handle the technical implementation side of this, but there are some pretty distinct differences. I can say from a higher-level working on wire-frames and working on mock-ups, you’re not designing this thing as a web site with things like hyperlinks. It’s not a traditional web application. You need to sort of put yourself in the headspace of designing at a native experience for users. It’s lot more akin to designing an app for a Mac OS X then it is to designing a traditional web application.
RM: From a technical perspective, there are quite a few differences that you will stumble across as you are coding designs into SproutCore. Fortunately, most of them are easy to move past once you get your head around SproutCore’s way of doing things. The largest hurdle for me to overcome was the fact that all views in SproutCore are absolutely positioned. Coming from a world outside of the framework, I was used to building things such as fluid grids using percentages. In SproutCore, not only are views absolutely positioned, but you must also use pixel based values for everything. The SproutCore team does have valid reasoning behind their decisions, but it is a different way of thinking, especially when ensuring the scalability of your application. Another little gotcha to keep in mind is that all views have overflow set to hidden, which is the opposite behavior you would expect, if you were building a website outside of SproutCore.
FC: Could you take us through what the process or processes are that you had to go through to style a SproutCore application?
RM: That’s an interesting topic because we ended up writing the CSS for Eloqua twice. The first time around, we built on top of the CSS that ships with SproutCore and we used its default theme at the core of our design. Round two of the styling consisted of us stripping out all CSS that’s bundled with SproutCore, including foundational code that a typical developer wouldn’t touch. We then re-wrote all the CSS in our application from the ground up. The main reason for the change was that we wanted to take the cutting-edge CSS3 approach instead of the image-based option that SproutCore opts for. When evaluating our original code, we also realized that we had a lot of overrides and really long selectors competing with SproutCore’s selectors for specificity and we could reduce our code base significantly by redoing things. In terms of outlining the exact process we took to style our application, I’m reluctant to talk about that because we did things at Eloqua that might not apply to other developers and I would hate to confuse anyone or lead them down the wrong path.
MG: I will say that when we started redoing everything in CSS3, I wouldn’t say it was a risk for us, but we were moving a little bit ahead of the curve using things like rounded corners, box shadows, etc. And it actually worked out really nice for us, because we found out over the last couple of months that there are apps, like new Twitter rolling out, that rely on CSS3 heavily, and it’s really becoming the norm at this point. I would recommend, absolutely, that if you are a writing a SproutCore application to look at using CSS3 for your controls as opposed to images.
FC: You’re taking about the stock controls?
MG: Ya, and I think that is one area where I’ve been sort of working on and off on a new SproutCore theme. But I would love to really see a stripped down, basic DOM structure that we could use, and then have users plug their own CSS3 properties. Kind of like flex builder.
FC: If you were a web designer who is going to use SproutCore, what would be the best way to get started? What lessons would you pass along to a web designer?
MG: I think the first thing is, when I started working on Eloqua10, about a year and half, two years ago, I had experience writing CSS, writing HTML markup, not nearly as much as Ryan, but, me as a newer web designer, starting on SproutCore was actually pretty straightforward, because I think the most difficult and complex portions of CSS are layout, alignment, relative positioning — having a fluid interface. With SproutCore, since it is fully, absolutely positioned, for a new designer it was actually quite a bit easier. You can understand that x-zero, y-zero is the top-left; you sort of offset everything that is relative to each other. I think Ryan as the exact opposite answer [laughs].
RM: [laughs] Yeah, I have different feelings simply because of my experience outside of SproutCore and spending time to learn best practices and techniques, such as the previously mentioned fluid grids, from greats such as Ethan Marcotte and Dan Cederholm. In SproutCore, it’s just a different mindset and once you get past that, you’re good to go. The best advice that I could give someone new to SproutCore is to go through all of the CSS that ships with the framework prior to implementing your own designs. I made the mistake of jumping right in and I had a lot of confusion due to the behavior of certain HTML elements. Confusion that could have easily been avoided, had I reviewed the code I was using before actually using it.
FC: To get a bit more technical, when you start creating your own custom CSS, either for stock views or for custom views, where do you normally put everything? What did you technically have to do to make sure that you had everything up to date, and what tools did you have to use in order to keep things consistent?
RM: As I mentioned before, we use a bit of a different process than others likely will. Basically, there is a folder named
standard_theme. You can choose to put your code in there if you like, or as we did at Eloqua, create a new folder for your custom work.
MG: It’s all driven by an additional class in the body tag. That’s how we differentiate.
RM: Right. By default, a class of
sc-theme gets applied to the body tag. You can change this to anything you want and easily switch between themes. As for tools, we use standard development tools like TextMate, and git for version control. I do recommend checking out Chance though. It’s an automated spriting tool for SproutCore that will make your life a lot easier.
MG: Just to add to that, if there was a single piece of advice that I would give to visual designers and people working a little more upstream, I think it would be, initially, your inclination is to look at the control set that ships with SproutCore out of the box and think that I’ll need a custom control here, this will have to be custom, that will have to be completely custom, etc, when, really, what SproutCore ships with is essentially the same building blocks that you get with Mac OS X for building applications. And when you break down the design and look at its moving parts, it very often consists of standard controls that SproutCore ships with without having to rely on some crazy, custom stuff that you may feel inclined to use.
FC: It’s interesting that you bring that up. When you talk about creating your custom control, from a design perspective, do you first start thinking about what kind of stock controls you can reuse for this custom control, or do you just start thinking about what the feature is, start putting it together in PhotoShop, and then start breaking it out? What is the process behind a custom control for you?
MG: It usually starts at the wire framing stage where you’re looking at what types of objects am I going to be working with — database objects that is — and what are the relationships. So am I going to need some kind of master-detail view? Is it a single pane? Am I going to need a palette? That stuff usually starts coming together at the wire framing stage. When you’re just starting off with your application, you’re going to probably sprint ahead and you’ll design one list view one way, and when you’re working on a different interface you might feel inclined to do a different list view a different way because it’s special. I think there’s also an inclination to think that your requirements for a specific area of the application are special, but generally it just requires perseverance and sticking to the core set of controls to ensure absolute consistency.
FC: Ryan, from your perspective, when you’re dealing with custom controls, what does it mean designing or applying CSS and working with the people who are actually writing the control’s logic?
RM: The process we use at Eloqua, which has proven to be effective, is that I’ll spend a few minutes writing up a suitable DOM structure, based on Matt’s mockup, and I’ll pass that static HTML file off to our developers who can use it to do their thing [writing the view’s rendering and behavioral logic]. When they’re done with what they need to, I grab the latest code from our git repository and proceed. We’ve managed to really streamline the process and eliminate a lot of the back and forth.
FC: Where there any points in time where you had to dive into the SproutCore code yourself?
RM: Yeah, I wrote some view code myself. In the SCUI framework for example, developed at Eloqua and open sourced, I wrote the code for the date picker. With a few lessons from one of our developers, I picked up on how to write code in SproutCore pretty quickly, despite coming from a design background. It’s really not that bad.
MG: Yeah, agreed.
RM: If you’re a designer, I highly recommend diving in and building view code too. At the end of the day, even if you’re not writing the view code for your application, just understanding it will go a long way with performing your other duties.
MG: Yeah, if you know HTML and you know how to write CSS, it’s not a big jump. It’s a pretty natural transition actually.
FC: If you were allowed to start over again, from a designing and styling perspective, what would you differently? What would you do the same?
RM: What I would do differently goes back to what I mentioned before. Learning the ins and outs of the framework before starting development, not being afraid to dive in and move outside of my comfort zone, etc. As for what I would do the same, well, everything else? [laughs] Seriously though, everything else would remain largely unchanged. My experience building websites outside of SproutCore was transferable to SproutCore development for the most part.
MG: So for me, one of the things that I would change, and we ended up sorting this out and I think we are in really good shape now, when we started designing this thing two years ago, we started to build patterns as we went. And we would have meetings and discussions and we’d make decisions as far as interface patterns in-stream during releases — it’s nice and agile. But what you find is that you end up coming to the right decision five months into the process and then having to go back and match the ideal decision. As much as you want to jump in right away and start playing around, which you should definitely do, when you’re actually getting serious about designing and implementing your application, it’s really important to define your world. Defining your world comes from making decisions, like, in a modal window, is a positive button on the right or the left? Are we going to have an “x” button in our modal windows? Is that going to be on the right or the left? Making those decisions early on and enforcing the consistency of those decisions leads to a cleaner, more compelling experience. Things I would keep the same would pretty much be everything else. There really isn’t much else I would change as far as the application goes.
FC: To quickly go back to the patterns: Did you have to come up with a lot of style patterns for consistency, or was is it just a hand-full and that was about it?
MG: By default, SproutCore sort of leads you in the direction of Mac OS X interfaces guidelines. So, for example, they have capsule buttons, they have square buttons; each one should be used in its own situation. They have a certain way of doing tabs. So you sort of are already being pushed in the direction of Apple, which is absolutely a good thing from a design and usability stand-point. The things I’m talking about are more of the micro decisions, like the examples I gave before; figuring out how much spacing are between elements. Those are the sorts of things to define and stick to.
FC: Where do you see the future going with web applications that look and feel like either desktop- or iPad- like apps? And following that up, what, if anything, does this mean for the web designer community in general?
MG: Good question. Well, I think it’s clear that we’ve hit a point in the history of the web where we finally have the ability to create these native experiences where people aren’t limiting themselves. They’re not jumping into the web application with the expectation that, oh, it’s a web application so it’s going to be a lesser experience. People are really starting to push the envelope. I think with SproutCore at the forefront, it’s very clear that the writing is on the wall that this only going to increase and it’s definitely where the future it. You’ve got all these companies out there trying to provide these experiences that are device agnostic while still providing a tailored experience. So it’s absolutely the future.
RM: I think Matt did a pretty good job of summing up my thoughts. It’s a daily occurrence now that I browse the web and come across another application that I’m shocked isn’t desktop based. People are starting to build extremely powerful applications on the web, and with SproutCore, doing so is much easier. It also helps that browsers are rapidly advancing and eliminating some of the technical challenges.
MG: And as HTML5 continues to be developed, continues to be adopted, and becomes more mainstreamed, you start to see interactions between the web and the desktop. So, for example, in Eloqua we have a couple of design interfaces. We’re looking at the ability to drag an image from the desktop directly into your web application, or if you want to upload contacts into the system, dragging an Excel spreadsheet directly from your local hard-drive to the cloud and having that transaction be seamless through a simple drag and drop gesture. Really exciting times. In the past as a designer working with the developer who is actually doing the implementation, you would almost be limiting yourself at the wire-frame or the mock-up stage knowing that there are going to be some kind of limitations there preventing you from getting to your sort of nirvana state of design. I think the big change here is, start pushing it. A lot of these walls are breaking down, there are a lot of emerging technology that are hitting critical mass, and it enables you to do all the stuff that you would ideally put into your design. So stop settling, stop compromising and start pushing the envelop more.
RM: Right. It’s mind-boggling to just take a step back and think about how rapidly things are progressing. The collective effort of developers and vendors pushing the web forward is really remarkable. Internet Explorer has even joined the party with version 9. It’s a really exciting time in a really exciting industry, that’s for sure.
FC: Great! Well that wraps up our interview. Thanks to Matt and Ryan for their time and input!