From Henry

SASSy Shopify Workflow

I recently started building a Shopify template for a client and one of the most difficult barriers to getting going was getting myself set up with a sensible workflow. As far as I can tell, there are four main ways to work on a Shopify theme from your desktop:

• Work on the files on your local machine, then zip them up and upload them via the Shopify interface. A poor solution, so much so in fact that it’s not really a solution.
• Use the shopify_theme, a command-line tool on GitHub which will watch a folder and upload files as they are saved. This looks like it could be a good solution but I found it to be a little unstable at times, often silently throwing errors and quitting. “Contribute to it then!” You might shout. To which I will reply “No! Too lazy!”
• Use the Shopify TextMate bundle. I tried this out, but it requires that you use TextMate (I’m a bit of a Sublime Text) and doesn’t seem to have a feature that automatically watches the directory you’re working in, although please correct me if I’m wrong. There seems to be a plugin for Sublime Text too which is a port of the TextMate bundle, but it doesn’t seem to have a huge amount of support. I played with it briefly but it seemed a bit temperamental.
• Use Shopify’s own Desktop Theme Editor which sits and watches the folder you’re working in and uploads files as you save them. It has it’s share of issues though and I’ll address them below.

Shopify & SASS – Not best friends.

While I eventually decided that I would use the Desktop Theme Editor to create my site, it still gave me the runaround – especially when working with SASS.

I have set up an automatic SASS compiler on my computer (CodeKit) which will watch my SASS folder and compile on save. As soon as I started working, I found that the Theme Editor was crashing whenever I tried to save my work. Infuriating so say the least. For some reason, Theme Editor doesn’t like dealing with sass compilers, so with a bit of hunting I found that the thing to do was to put the sass files outside the main theme folder, and configure the compiler to compile the CSS straight into the assets folder. With that problem sorted, I was on my way! …Until I wanted to embed liquid tags in my CSS.

Liquid & SASS

While building the site, I realised that I was going to hit a wall as soon as I wanted to start embedding Shopify’s liquid tags in my CSS. To do this though, you need to start effectively write invalid SASS; tags that should be interpreted by Shopify at runtime. Not only that – your myfile.css files need to be changed to myfile.css.liquid which SASS compilers don’t compile to. Does this really mean having to change the file name every time you save? Fortunately not in the case of CodeKit. It turns out that in CodeKit at least, you can catch the stylesheet saving process and run your own Ruby code. So the following code will rename the file that was just saved for you!

on_stylesheet_saved do |filename|
 FileUtils.mv(filename, filename + ".liquid")
end

That’s that sorted, but what about those pesky liquid tags? Well that’s easily overcome with a bit of SASS magic! (Interpolation)

#{' {{ "established.png" | asset_url }} '}

It’s all a little bit messy but hey, I can live with that until a better solution comes along. I use a Mac, and a lot of these tools are Mac-only so Windows and Linux users, you’re on your own! If you find a better way of working with Shopify Themes get in touch – I’d love to hear it!

The case against PhoneGap

PhoneGap is a clever piece of engineering. It allows the developer to build an app for a mobile platform such as iOS or Android and deploy it to run natively on a vast multitude of other platforms without necessarily having to make any changes to the codebase. This is fantastic for both the client and the developer, right? The client gets to have their app available to a huge user-base in a short amount of time and the developer can save money by cutting development costs. Surely the whole thing is a win-win money-making appalooza! Well, not really.

Native Beauty

As an iOS developer I am going to approach the subject from this perspective, but to an extent the same points apply to the other platforms too. iOS is a great operating system to develop for, it’s Core Animation layer, XCode’s easy Interface Designer and the device’s high resolution displays all allow developers to turn what could be a usable application into one which inspires delight from anyone using it. This is how native apps should be. Delightful. And this is where PhoneGap misses the boat.

A byproduct of multi-device, one-size-fits-all development frameworks like PhoneGap, is a distinct lack of delight and elegance. Apps like Path, Instagram and Foursquare are a pleasure to use. Each of them have been developed natively for their respective platforms and it really shows. PhoneGap is the equivalent of a supermarket microwave-meal when you could be having a carefully prepared delicious meal from a good restaurant. Sure the microwave meal is quicker and cheaper, but would you really pick that when offered the choice?

But…App Store!

So, what if the client can’t afford the development time that goes into a natively developed mobile app? Well, there is already a great framework out there which provides a single-codebase solution and which is flexible enough that almost anything is possible. It’s called HTML. Why wrap a whole bunch of HTML into a psuedo-native app when you could just use the web itself? I think that one of the primary reasons that frameworks like PhoneGap exist is because of the App Store. Apple introduced the idea of a centralised application distribution platform to the masses in 2008. It’s now 2012 and it seems like everyone and their dog has an app store of their own. This of course means that companies want their products in the app store. PhoneGap offers this, and this makes it much more of an appealing alternative to a website somewhere that few people will ever stumble across. And what’s more, its so easy to monetize!

What should we do?

As someone who is a sucker for beautiful interface design, I hate to see this lowest-common-denominator approach to app development taking hold (not to mention the uncertainty of developing solely on someone’s framework which will one day inevitably no longer be supported). It’s not the fault of PhoneGap, they just catered for a demand. Nor is it the fault of the clients. They’re just trying to get the best from their budget. We, the developers and designers who want to be proud of our next product need to educate our colleagues, bosses and clients in the long-term value of good craftsmanship for the benefit of the customers and therefore the client’s profits.