And you are here why?

It’s a pretty nifty saying, isn’t it? Unfortunately it only works for when You don’t understand how it works, and/or You’ve got too many other things to worry about. The problem, of course, is that  if you don’t understand how it works, how do you know it’s not broken?  Murphy’s law being what it is, you know that the break will reveal itself at the single most inopportune time, right? Ok, that’s not actually fair to Murphy. Broken parts tend to fail under stress, and fail disastrously at that. And stressful situations are typically the situations in which you need the largest amount of cognitive bandwidth to deal with the ongoing chaos, and the last thing you need is something (critical!) rupturing on you. So yeah,  of course , the break will reveal itself at the worst possible time. And that is kinda the point he re - if you don’t understand the mechanism, saying “if it ain’t broke, don’t fix it” ‘cos it  seems  to work is, quite possibly, the worst possible t...

/via http://www.commitstrip.com/en/2016/10/10/a-story-about-css-units/ CSS Is Awesome! No, really, it’s awesome. It’s awesome in exactly the same way as  emacs  is awesome, in that spending 6 weeks away from it means I have to re-learn every damn thing I knew all over again. And yes, I’m saying this because I’m looking at a bunch of CSS that I  know  I’ve tweaked successfully in the past, and it’s all greek to me. Or rather, it’s all CSS to me. Sigh. 

Is your product a   Tool   or an   Agent?   The difference between the two is crucial, and if you don’t capture it in your product design, you’re doomed to failure (or, at the very least, sub-par user engagement). So, what’s the difference? Well, a tool help   you   do a task, while an agent does a task   for   you. Or, to put it differently, think   Hammer vs Concierge . Tools   are, effectively, part of your body. They are ready to hand, and you use them almost unconsciously, with immediate feedback.  Think of the way you use a hammer — it is, effectively, an extension of your arm, no? You’re not guiding the head of the hammer to the nail, you just swing your arm, and   thwack   the nail in. Towards this, the product design for Tools should be focused on keeping you “ in the flow ”, on removing any externalities that get between you, and the thing that you are doing. Agents , on the other hand, are   externa...

In todays episode of “ Lets Talk About Stuff You Already Know ” we cover  Loose-Coupling . The  baseline definition  is kinda obvious — it’s a system is which each component has limited knowledge (and use!) of the other components. That said, if that was the extent of it, I would just have linked to  the Wiki page , and have been done with it. The thing is,  semantics are important , and what the term means to me is not necessarily what it means to somebody else. Given that the most costly software issues tend to be the ones made earliest, it behooves you to limit misunderstandings in the  Design  stage! Consider a simplified take on the development cycle, viz.  Design → Develop → Test → Deploy . With a loosely-couple system, you can • Design  your component with limited involvement from other components. Whats more, you can update this design without  other  folks having to change  their  stuff. • Develop  y...

Say “ Technical Debt ”, and the visceral response is usually a shudder, with the mental image being a combination of “ Stuff we f**ked up ” and “ All those shortcuts we took ” It’s not necessarily wrong, but one that doesn’t quite capture the entire picture. Me, I tend to think of  Technical Debt  as a continuum, with a lower bound based upon the tension between  Building the Right Thing  and  Building the Thing Right . Knowing that the lower bound exists is important, as it helps prevent  overthink . Building the Right Thing:     Knowing what you are trying to build is  hard . I mean, just think of all the different areas that stuff can get screwed up in • Your customers get mixed up between what they want, and what they need. • You don’t get the requirements — whatever they are — exactly right from them • Your team all interpret them differently — even if only slightly, it’s still not exactly the same • The technologies that y...

It’s 2018, and you think we’d have figured out UX for Forms by now, right? OK, maybe not  all  of it, there is still a lot of subjectivity in the field (hah, a pun!), but the basics, oh yes, the basics,  those  we should have figured out right? And yet,  yet , witness the infinitude of sites, apps, and services where things are great  as long as everything follows the golden path . But take one step off the path, and BAM, all hell breaks loose. So here, all of you form-designers, Four Basic Steps that you can follow to not make all of our lives a living hell. Oh yeah, you can still screw up all sorts of stuff, but these, please, you have to get correct! Step 1 .  Don’t have errors in the first place Seriously, if a line of javascript would prevent me — or others — from cursing, go ahead and do it please? For example a) Preventable stupidity : Tell me that the date-format is invalid ( MM/DD/YYYY , not MM-DD-YYYY ) while I’m filling out the...

Good   #UI   design isn’t just about being “user-friendly”, it’s about   reifying deep principles about the world, making them the working conditions that users live and create , making explicit, yet comfortable and familiar, becoming part of the user’s patterns of thought. #MachineLearning   can be valuable here — removing vast swathes of cognitive burden to expose these deeper truths. Consider Font Design for example — bolding a font isn’t just about “making it thicker” () — there are a bajillion heuristics that type designers have figured out over the ages, things like “preserve the enclosed negative space”, “move bars lower”, “lag interior strokes to the exterior”, and hundreds more (Thousands? Even more? Quite likely…) The benefits of using   #AI   to help is that you can train it on these heuristics, using available fonts, and it will automatically generate the bolded versions for you. Oh, it won’t be perfect the first time around, but use you...

with apologies to Claire's mug

Its a " Fletcher Capstan Table ", and has a fairly long history, with the original one being patented by Robert Jupe in 1835. This particular version is designed for (very expensive!) yachts ...

From the minds at Otaat (One Thing At A Time), comes the ultimate in Fetish-wear - party hats . Just the thing to accesorize with your cod-piece, eh? There are some things that I just can't make up...

Stephanie Rieger initiated the latest dust-up involving screen sizes.   The problem, as she points out, is that "Android" really isn't about one device, and one screen size - its based on a combination of "Actual" screen resolution Browser views (browsers embedded in other apps like facebook and twitter), where the "shell" sucks up some real-estate Settings like "Zoom" Viewport orientation based on portrait/landscape and oh, so many more things (By the way, the article is about Android, but the same applies across iOS, RIM, etc.) This actually takes me back to my early days in the web-world (1993, natch) - when you had only Mosaic (and Netscape 0.9 in '94) to contend with design decisions were easy.  Very shortly thereafter, life became a living hell , as you had to start designing towards various iterations of Netscape, since each version came out with its new set of HTML tags that made life so much easier, yet complete...