Paul Hammant's Blog: When Agile meets Angular and UX-led development
UX Led Development?
This is where your User eXperience (UX) developers are active within a dev-team, pushing the experience, behaviors and interactions. Pushing in this context means rapid evolution of a working UI. Imagine the UX saying “like this?” to a product owner, perhaps quickly followed by a reactive “no?, OK then, hang on …” clickety click “… how about this?”. To me at least, those clicks are on source code in some form, and when the product owner (or client) is happy and walks away, then the UX is able to commit to source control (providing they did not break any tests). Of course UX developers are not able to code all the way down the stack, so this ideal breaks for many technologies.
Angular?
Angular, for web-applications, is a great facilitator of UX led development. It does not need a functioning back-end in order to be developed or demonstrated. It just needs co-located static JSON documents that could have come from a functioning back end. I have a real example of that setup with StoryNavigator. That page uses a static JSON document that was pre-made. It’s all quite easy, and it was a UX fellow, Frank Villa-Abrille who designed and coded the page, while being new to Angular. He started with just the JSON document (output from a JBehave test run) and some whiteboard sketches. That finished product:
With the Angular import turned off (to help the UX devs code fast):
Pretotyping
With such a nimble tool-chain you might trying to work in as much from the thinking around pretotyping (see a video on this) as you can, to keep things cheap (particularly mistakes). An earlier stage would have been paper-based, but you’ve pushed past. You also skipped the comps stage, and are trying to use a subset of the final product to evolve the experience.
The problem in the Agile age
Sometimes you are going to run ahead of where you and the customer are currently discussing and signing off. Perhaps you know exactly what you’re making functionally, because you’re re-writing a product that is already live (new technologies rather than a refactor). The customer is talking about fine grained behaviors and aesthetic, you’re trying to concurrently work on future aspects of the system, with Business Analysts (and the PM) feeding the back-end developers concise & defect-free stories to code.
Alberto Savoia (the presenter in that video, and “owner” of pretotyping) has an “Impostor” tactic which proves useful in that regard. One technique, in short, is that you could bootstrap on the old stack to quickly/cheaply show functionality to the product owner. Martin Fowler wrote an article on the Stranger Strategy for replacing something old with a newer version in increments, but I digress.
The problem is when you are show-casing what you’ve made so far with people outside the dev-team. Being UX led, you might have some bits that work, and some bits that would work were there back-ends hooked up. This is because your UXs have pushed ahead. Of course, you could use multiple branches (private ones, and/or public ones) to juggle the concurrency we’re talking about, but there’s an elegant simplicity to trunk based development branching models, especially when you use Feature Toggles.
As we used to do it, with Server-Side MVC
In the old server-side MVC world, you would use custom conditionals in page templating. In Java Server Pages (JSP) rather than ugly if else end code, you would use Taglibs:
<%@ taglib uri="/taglibs/feature_toggle_taglib" prefix="toggles" %>
<body>
...
<toggles:feature name="freeCheese">
<div class="cheese">
...
</div>
</toggles:feature>
...
</body>
How that maps into Client-Side MVC
Whereas I’d initially thought that feature toggles didn’t apply to static HTML pages, colleague Shaun McGee asked if Angular could obey toggles, and of course it could. In the new world of client-side MVC, the pages are static, not dynamic as served up over HTTP, but there is still a dynamic nature in the page. In your trunk you could do the Angular equivalent:
<body>
...
<div ng-show="toggles.cheese" class="cheese">
...
</div>
...
</body>
Different teams working concurrently in the trunk set different defaults for cheese in this case. Either true or false depending on whether they are need to see that feature. You’d engineer a way to flip that toggle programmatically (like for all runtime toggles). When you do a show case, you make sure you set that toggle appropriately so as not to confuse who you’re demonstrating to.
It might also be as easy to have a single feature toggle to mask what you can’t show-case ng-hide="toggles.notForShowCase".
For actual production releases?
You can’t actually push that live. The JavaScript in the browser is fair-game for hackers and journalists. That you have some secret ‘cheese’ feature waiting in the wings is easy to spot, and would shine some unwelcome light on “Dark Deployments”. For production releases, as part of production hardening on release branches (via UAT and staging environments), you’ll have to excise the sections that are conditional on toggles that are not intended for public scrutiny. You could try some multi-line regex to do that in a script, but might experience costly side-effects to cause you to regret that decision. Better would be to use a human to make a commit on the release branch after searching for ng-show="toggles.cheese" and correctly deleting the elements using them.