Erik D. Kennedy, 7 Rules for Creating Gorgeous UI (Part 1):
This is the Krav Maga of screens.
Definitely worth reading, especially if you’re one of those folks that tends to think that great design only comes from this small subset of “talented” people. Nope: there are a few basic rules, and you can learn them. (And here’s part two.)
learn data structures
Soviet propaganda
late summer flowers
“Search Term Haiku” is a series wherein I examine this site’s log files and construct one or more haiku poems from search terms and phrases that led visitors to the site. Where possible, I attempt to keep the search phrases intact. However, as these are haiku poems, I do need to follow the rules.
Thanks for clearing that up.
William Gibson, The First Sentence Is a Handshake (interview in The Atlantic)
Writing the first sentence of a novel, for me, is something like filing, from a blank of metal, the key for a lock that doesn’t yet exist, in a door that doesn’t yet exist, set into a wall … An impossible thing, yet I find it must be done, or at least approximately done, else nothing will follow. The white wall (once of paper, now of pixels) will only open to the right key, or at least something approximating it, as I tend to keep filing, endlessly, through the ensuing composition.
And the rest is even better than that. But this quote here was a light bulb for me. In that moment, his words described the act of writing as something very familiar to me, but also something very alien and strange and brilliantly true.
Jeff Whelpley, “Screw You, Angular”:
Recently there has been a great little triangle of battles going on among Ember, React and Angular. The reason why these debates are so great is that each of the frameworks have various pieces that are pure genius (ex. Angular DI, React Virtual DOM, Ember Router) and it is not abnormal to see developers in one framework borrow the great idea from another framework (ex. Angular UI Router from Ember Router).
If you just go by the title and/or aren’t paying attention through the first couple of paragraphs, you may be tempted to believe that this is yet another post dismissing AngularJS out of hand due either to its recent controversy over the 2.0 announcement, or else using that announcement to underscore a previous dismissal. But if you stick it out to the end, you’ll see that he’s trying to re-frame parts of the conversation around what it means to use a framework in the first place, and where the anxiety and friction is coming from. We want frameworks that take advantage of modern features and have streamlined APIs, but we’re afraid of having the rug pulled out from under us.
And/but: the two addenda to the post are where it’s at. First, that he’s explicitly calling out the anxiety around the upgrade path. And second, that he’s pointing to the fact that there’s such good competition out there between frameworks and that they’re cherry-picking good ideas from each other.
Amy Chess, The User Experience of… Fixing Things:
Why do I tell this story? Mostly because it’s an example of a problem that found a solution, rather than the other way around. But also because it illustrates why people require solutions in the first place: because they are in crisis.
She brings up a good point here about empathy: that it’s the critical tool in the UX researcher or designer’s toolkit because she is not faced with the same motivation-generating crisis that the person on the other end of the problem is.
This is something that’s worth remembering whether you’re doing design work, user research, or development.
Why Web Tools Like AngularJS Need To Keep Breaking Themselves: Matt Asay, writing for ReadWrite.
tl;dr: AngularJS 2.0 is targeting the future because the future is where we’re going and anyway let’s not forget that the existing architecture/design is at least four years old anyway, and who’s on a 10-year software development lifecycle anymore?
In large part, I think the points that he’s making are good, but easy to make. What he doesn’t seem to address, and is the thing that keeps coming up in the conversations I’ve been having, has been the real-world developer concerns around the upgrade path. Or rather: the fact that none has been communicated. In other words, “the point” of picking a framework like AngularJS has a lot to do with not wanting to solve the problems that are not central to your application’s domain. You’re building a travel planning app or a photo sharing site or a CMS or… fill in that blank with just about anything. You’re not building dependency injection and data-binding and a whole host of other abstract things because… well, that’s not what you’re customers are paying for. And I think that by and large no one minds the occasional refactor of their application, so long as the things that you’re refactoring are your features.
Not having an upgrade path is a source of anxiety because it goes from feeling like a “big refactor” to “complete rewrite”. This is the cringe that I hear in everyone’s voice.
That being said… (1) I’m still not convinced that we won’t see any upgrade path – even if it’s a painful one. And (2) I agree that we want the frameworks we’re using (when we’re using them) to be powerful and tap into the powerful underlying modern APIs.
Hackathon drama
a git cherry-pick problem
ends with API
Well that one came out rather nicely.
“Search Term Haiku” is a series wherein I examine this site’s log files and construct one or more haiku poems from search terms and phrases that led visitors to the site. Where possible, I attempt to keep the search phrases intact. However, as these are haiku poems, I do need to follow the rules.
RE: Optimize for change. It’s the only constant.
Alas – the snark and schadenfreude are terribly unconstructive and show a shocking lack of empathy from someone who has otherwise gotten a rather fantastic reputation for having exactly that kind of empathy.
There’s an unstated assumption that people selected AngularJS for their projects simply because it was “backed by Google” or because it was some kind of shiny thing that everyone was playing with “at the time” – and while this may be true for some, there are many who have done their homework and did their framework/library bake-offs and looked at their specific situations and said: “You know what? AngularJS is the best solution for us for these legitimate reasons.”
Right. So the schadenfreude? Not helping anyone.
Which is unfortunate, because this point is really good and really important:
As a leader on a dev team, I personally consider it too risky to invest our team’s energy in learning the intricacies of a particular framework; I want our team to learn how to solve problems in JavaScript by combining the right tools for the job.
And/but here’s the twist: your customers never give a shit about what language or framework or library you use to solve their problem, they just want you to solve the problem. In that respect, domain knowledge is more valuable than any piece of technical minutia you’re picking up along the way. Which is not to say that that technical knowledge is not important – after all, these are (probably) the tools you need to use to solve exactly the problems in that domain you’ve worked so hard to learn something about. Which brings us full circle: do you burn time writing your own thing? or searching for and stitching together the little libraries? or buy into that larger framework which is going to allow you to off-load a lot of that?
Each team needs to decide this for itself. What trade-offs are you willing to make to get where you’re going? Because don’t believe for a second that you can just pick “a loose collection of a bunch of optional modules” and say that you’ve “optimized for change”. You’re just choosing a different set of dragons to wrestle with.
And anyway, everyone needs to draw a collective deep breath and chill the hell out over this. (1) Your software choices and architecture designs are always wrong to someone. (2) Maybe this event serves as an important wake-up call to you and your team and you come out on the other side of it having learned some valuable lessons about how to build front-end apps. (3) And/or just because no AngularJS upgrade path got announced doesn’t mean there won’t be one and maybe 6 months from now there’s a blog post that reveals just how everything is going to be just fine.
Regardless: relax, don’t worry, it’s just software.
UPDATE: Just about as soon as this was published (after simmering overnight as a draft in the queue…), I saw that Joreteg has re-written the post to be… less harsh. I’ve decided to leave my post as-is because if nothing else it will serve as a reminder to myself that we can all act too hastily in our responses at times. The main points of my own response remain the same: (1) try to be constructive in your criticism; (2) do your own research and make the right choice for your team; and (3) maybe just maybe it’s still too early for everyone to freak out as much as they have.
My favorite part of Joe Colantonio’s review of PhantomJS Cookbook
This is not a book on theory; it is the real lowdown on what works with PhantomJS by someone who has years of hands on experience. Consequently, Rob’s recipes cover the most common scenarios you’ll likely face during your development efforts, so you’ll be learning practical recipes you can put to work right away.
Mission accomplished.