In the last six months I have worked on a few large scale products built with Angular.js. I thought I’d share a methodology I have been getting a lot of mileage out of, which I’m calling directive-as-service.
The usual premise is I’ll be working away on a UI and have a need for a components that are related to the part of the interface I am working on, but kind of not really owned by it, and not necessarily a child of it. Things like modals, context menu, progress indicators etc.
To add a twist to the problem, I may not have direct access to the page layout html and I prefer to inject markup like this into the document root to avoid css selector pollution.
I solve this by creating a service which compiles a directive on demand. This makes my directive available via angular’s dependancy injection, and the injection of the directive into the document can also be nicely abstracted by the service.
You’ll notice the service below generates a new root scope, and passes parameters to the directive. I find this makes usage a bit simpler and more predictable than inheriting scope, though it’s easy to inherit the scope using this approach as well, just pass the
$scope from your controller to the service instead of a params object and don’t bother new’ing up a rootScope.
Using this directive-as-a-service approach, it makes it very easy to module-out these UI components to be shared across projects, reducing implementation work to including the module and injecting the dependancy to your controller.
The only manual consideration at that point is css, but I suppose if youre feeling shameless you could write that into your directive code as well.
Typically, a project will have grunt and its task libraries packaged in via NPM, and then configured in Gruntfile.js.
As it happens, Grunt is designed to be configured in a much more modular manner, via the
Using the following approach we can have a seperate .js file for each task (eg. run jshint, concatenate files, compile .sass to css, upload to S3) which we can then treat like plugins to our grunt system.
To maintain modularity, I try to keep project specific proprerties, such as paths and urls in a a seperate config in the project root.
For most items, I add them to the node package.json file, which is checked in to version control. For sensitive items, such db credentials, I use a config.json file (a throwback to the config.yml days) which is ignored by version control and partnered with config.sample.json, which gets checked in as an indication of what keys are expected by the system.
This is still a hurdle that new people on the project can trip over, so you’ll notice below I make a big song and dance in the logs when config.json is missing.
One thing I havent covered are compound-tasks, such as “watch these files and, when they change, lint the scripts, concat them and shoot them up to S3”. For that I just place a tasks.js file in with the others and define them like so:
If you’re like me, you’ll just want do download an example project with all this, so here it is, and here are some of my commonly used task files.
It took me a while to piece together this approach from different places, so if anyone has better ways of achieving these goals Id love to hear you approach (@linkthief).
How cloud services can make your digital campaign production faster, better and more cost effective.
Most agencies still run digital campaigns today on what is essentially 90‘s technology. Meanwhile, looking towards the startup world we see a much different picture. Without the brute force an agency department can throw at a problem, startup’s have to come up with more elegant and creative solutions, often at a much greater scale than your average campaign. Agencies don’t always have the same constraints, but that’s not to say there aren’t lessons to be gleaned. One very common solution is the use of cloud services in leiu of investing in hardware while getting a product off the ground, which in my experience helps get a product out the door in less time, for less money and at a higher quality.
Advertising campaigns typically aren’t a long term business. Whether constrained by budget or audience attention, digital campaign runs are typically measured in weeks, not months or years. Traditionally an online deployment involves provision of shared or dedicated server hardware, bringing with them a high, up-front capital expenditure. If you’re not paying extra for a consultant to configure and administer the deployment, and nothing goes wrong and goals don’t change1, expense from that point should be relatively low.
Conversely, cloud/service powered deployments have zero up-front cost and have the agility to provision more or less horsepower as required over the run of the campaign. There is room for debate over the cost effectiveness of cloud computing for a long term engagement. You have the ability to resources up and down as required but there will always be a middle man between you and the metal, so all other operational expenses ignored, owning the stack yourself should give you more compute for your buck, in theory. The thing is, when the scale this economy-of-scale refers to is time, most ad campaigns don’t run long enough to reap the value required from a higher capital investment.
One of the comforting aspects of Apache/PHP/MySQL is that all you need to do to get a project up and running is drop a few files in a folder on a server.
In reality, things like local and external DNS records need to be configured, database schema’s designed, network shares setup and some form of version control implemented before you can get any real work done. That’s just for your development environment, you’ll have to do most of it again in production. My favourite cloud plaform at the moment is Heroku. Built atop AWS, Heroku provides a platform-as-aservice which runs Ruby, Python and Node.js based apps (among others). Getting up and running is usually a matter of copying a couple of boilerplate files, running “
heroku create” and then pushing the files up via Git. In a matter of seconds you’re looking at a live app, on a secure server, tracked in version control and externally visible for $0. Noticably missing from the supported languages is PHP (which is likely what your in-house guys live in). Which brings us to an interesting observation:
When building a digital team, it makes sense to build around a long standing, incumbent technology stack (LAMP). One which has mass popularity amongst developers (LAMP), where development may have slowed down a bit in its maturity but is perceived to be quite reliable and stable (LAMP). You have an ocean of talent to choose from. Which is actually kind of a problem. Similar to the problem of finding great creatives and designers you’re never short of resumes and books to look at. But to mix metaphors, that ocean of applicants is really just the opposite of shooting fish in a barrel. Post a job ad for Ruby, Python or Node specialists on the other hand and your’e much more likelye to get a smaller pool or highly skilled applicants. Given the popularity of the LAMP stack, most of these devs are going to have that experience anyway. Being good developers though, they have investigated alternative approaches and found them compelling enough to specialize in. It’s kind of like building a racing team. If you drafted your team from drivers of small hatchbacks, you’d have millions to pick from, and the talent would be out there. Somewhere2. However, if you drafted drivers of exotic sports cars you’d find lower numbers but passion through the roof.
I’m not going to make a habit of writing about the technology industry, but this week’s leadership shakeup at Apple has piqued the interest of the designer in me.
Alongside retail head John Browett, iOS head Scott Forstall has been shown the door. There is of course much speculation as to why, but what I find much more interesting is the implications of superdesigner Jony Ive taking over iOS UI design in addition to the industrial design.
Since Steve Jobs left Apple, even before his death, “This wouldn’t have happened if Jobs was still around” has been heard every time there is an announcement. But realistically, Cook has been running the show for years, hence very little changing since his official promotion to CEO. The two largely had the same vision at the 50,000ft level CEO’s operate on. The jobs to cook transition was effectively a name change, with very little executional difference.
Contrast that relationship to that of Ive & Forstall. The two have deep idealogical differences in design taste, come from very different backgrounds and it’s rumoured that in the end it was hard to get them in the same room. Forstall has reportedly always been Jobs’ guy and also shared some of his tackier skeuomorphic tastes. Ive on the other hand is famously a follower of Dieter Rams’ principles of design, which frames design as a subtractive endeavour, rather than the additive & decorative style Apple has utilised recently in its UI design.
So expect some significant changes in design. First, expect a much more coherent design resonance between the hardware and software now that the apparent departmental rift has been bridged. Expect UI decoration to fade in lieu of cleverness.
Ive isn’t dumb, these changes will come gradually. But this week will be looked back upon as a turning point for design at Apple.
There’s a line we can draw down the middle of digital content. On one side, we have the apps. Native apps, HTML5 apps, Flash, whatever. On the other side, we have documents; pieces of information, well formatted and neatly presented (hopefully).
Docs are what most of the web is based on. Informational pages, location & contact details details, menus etc. When you Google something, you’re looking for a doc. This is an important observation to remember. Docs need to be findable, readable, search engine friendly, bookmarkable and of course, mobile friendly. It’s less important now than it has been in the past, but it’s a good idea to make sure your docs print well too (it makes you look good).
Apps are the heavy lifters of the web. The greatest apps are task driven, pleasantly interactive, efficient and focused. Apps are commonly used to perform regularly repeated tasks, such as viewing photos, sending and retrieving messages and updating social data. The thing to remember with apps is that they require an investment in time on behalf of the customer, be it downloading a native app from a store or signing up to a web app. This is why building to deliver single-use content is rarely a good idea.
Different types of content and media lend themselves to being delivered as a series of docs or an app. Correctly identifying which of these your audience expects is going to make a big difference to the effectiveness of what you’re publishing. If your audience wants information, give it to them in the most frictionless way or they’ll get it from someone else who will.