Every time your app steals focus... God kills a kitten.
Every time your app steals focus... God kills a kitten.
I have a liking for terrible puns, so I have always had a soft spot for the analyst firm Horses for Sources. Their latest newsletter included a link to a blog post which I'd meant to write up the first time around, but got distracted… ooh! A squirrel!
Ahem. Anyway.
Here's the piece: Time to stop the buzzword balderdash and become meaningful again.
Am I smoking something illegal, or has our industry really started to lose the plot with the amount of buzz terms that – quite frankly – only mean something to the sellers and advisors trying to make their wares sound that little bit savvier than their competitors. And even then, I am not too sure whether many of them even fully understand what they are buzzing about either, more simply regurgitating what their competitors are saying.
They also provide a table of examples, which really doesn't look good for anyone talking about SMAC1:
I don't think the problem is with people parroting their competitors. Rather, in each company the "thought leaders" come up with terms like DevOps, cloud, or, yes, SMAC, and they mean something specific by them. Over a period of time when they are hashing out their concept, they develop these sorts of verbal shorthand to refer to quite complex structures.
When these deep thinkers are communicating the concept to outsiders, sometimes – often – they forget to provide the extended definition and associated context. Their audience of sales people and other front-liners half-understand the concept, learn the shorthand by heart, and end up in front of customers regurgitating poorly understood messages. The result is basically cargo-cult marketing.
The problem is not that the various visionaries have their own jargon, or even that they talk in acronyms. The problems begin when they come down from the mountain and forget to translate that jargon into common language. The point is not to sound smart to people who don't understand the concept, but to communicate that concept.
A theory that you can't explain to a bartender is probably no damn good.
--Ernest Rutherford
Hilariously, even Wikipedia's disambiguation page for SMAC doesn't have a definition for SMAC in this sense, just a link to let people create a page... ↩
all the trigger warnings
There is a Facebook page entitled "Elliot Rodger is an American hero" (no link, but you can find it easily enough). Facebook offers the ability to report pages that are harassing, so that's what I did - and look what their response is!
Apparently this page does not violate Facebook's Community Standards. These would be the same standards that get people in trouble for posting pictures of mothers breastfeeding, or the kids' bath time.
To quote from those Community Standards:
Facebook does not permit hate speech
, but distinguishes between serious and humorous speech. While we encourage you to challenge ideas, institutions, events, and practices, we do not permit individuals or groups to attack others based on their race, ethnicity, national origin, religion, sex, gender, sexual orientation, disability or medical condition.
I would say this is pretty obviously hate speech and not humorous in the least. Look, this isn't 4chan. I have no doubt there are already one million animated gifs of kawaii kittens acting out Elliot Rodger's shooting spree, complete with "Never gonna give you up" on the soundtrack, but that's expected over there. If you have no rules, that's what happens - but if you set rules, guess what? People expect you to enforce them, universally and fairly.
This isn't quite my "boycott Facebook" moment, but it's one more broken thread in the string that's holding me there.
Teleworking is back in the news!
The very technology that enables telecommuting and working from home could be destroying its value. Although productivity may increase in the short term, working from home may prevent your teams from working effectively.
I've had both office-based and home-office jobs, so I have an idea of the upsides and downsides of each. I last wrote about teleworking more than a year ago, when Yahoo first banned the practice. Here's what I said at the time:
... the office is where I go to have impromptu conversations and face-to-face meetings, but it's not where I am most productive, even with my headphones on. I am much more productive at home, in aeroplanes, or in hotel rooms without distractions.
I think the sort of togetherness that the Forbes piece describes is real. I work in a team that is entirely remote: no two team-members share an office. For the type of work we do, this works well. It's great to meet up, and we take every opportunity to do so, but mostly we're fairly loosely coupled, so we get on fine as is.
There is another dimension to consider here. If companies gather all their employees except for local field support into one central location, they may have all sorts of serendipitous conversations around coffee machines, but there is a significant risk of an echo chamber effect developing. Silicon Valley is all well and good, but what works there will not necessarily work elsewhere in the US, never mind Europe, Asia and so on. If everyone involved in deciding and communicating the strategic direction of the company lives their entire lives in Silicon Valley, surrounded by people doing exactly the same thing, the company will develop a huge blind spot to the realities on the ground.
Not to mention all the employees spending their bonuses on noise-canceling headphones just so they can get some work done in the office again...
Let me share with you a short e-mail conversation I had earlier today, which perfectly illustrates why users will do anything rather than deal with their IT department, up to and including running their own servers.
Me: Hey IT, what are the video conferencing standards we can support?
IT: Just use Lync - it's the standard!
Me: No, it's somebody else's meeting, and they asked what video conferencing standards we can support.
IT: I don't know anything about this meeting, and anyway it's up to them to send you an invitation you can accept.
Me: Agreed, and they are asking what I can accept, hence my question about which video conferencing standards we can support.
IT: * silence *
As usual, Dilbert is spot-on: I am obviously dealing with Mordac, the Preventer of Information Services.
I'm very late to the story, but I have some thoughts on the topic of URLs going away. Basically, the latest builds of Chrome no longer show the URL at all, following along with a trend which started with Safari on iOS7 hiding everything beyond the site itself by default.
The thing is, civilians have been using the web this way for ages. Few people type URLs or even truly understand how the things work. This resistance is not limited to HTTP, either. One of my pet peeves is the existence of services like Hightail (YouSendIt) or WeTransfer. Neither really does anything different from FTP, at least the way I see them used. If you ask users of these services, though - and I happen to have one handy in my house - they will tell you that FTP is "too complicated", requiring logins and thinking about complex navigation and permissions.
To me, writing out an FTP URL like ftp://
username@hostname/directory/file.ext
seems perfectly obvious and natural. When a user receives that URL through email or whatever other mechanism, they can click on it and be taken directly to the file.
The problem is that while I have sent many URLs like that, I can count the number of times I have received a URL formatted that way on the fingers of one hand. URLs seem obvious to me because I'm used to thinking of paths that way, but Muggles don't think that way, and don't want to. WeTransfer hides the scary details, and that's what they want.
My hope is actually that this move leads to the return of separate address and search fields, with the address field hidden by default. That way I could turn the address field back on, and finally be able to connect to hostname
on my local LAN instead of being sent to a Google search for "hostname".
I want to share a couple of stories, both via the Quartz Daily Brief email newsletter.
Car headlamps are good for cannabis. Gangs are nicking LED bulbs from luxury vehicles to use as growing lamps.
What to do about a problem like that? Quick fix: legalise weed, save the LED headlamps!
Not so fast:
Legal weed leads to cheaper heroin.
Mexican pot farmers stung by cheap US competition a
re now producing opium instead
.
This sort of thing happens all the time in IT too. There's a problem, a quick fix is hacked together, and now we have two problems: the original problem that didn't quite get fixed, and the new problem of maintaining the fix.
If you have an issue, and your first reaction is "I'll just write a quick script to fix that", step away from the keyboard and think again. That quick script takes time to write, and then more time to rewrite properly once you figure out all the edge cases and conflicts. Then it takes even more time to maintain and update over time.
There's a big opportunity cost in doing all that work. Think of what you could (or should) be doing instead. Prohibition pushed good scientists out of oenology, in effect jumpstarting food technology. Everything we do has consequences, and most of those are unforeseen.
A piece I wrote on Heartbleed was published in Cloud Computing Intelligence magazine:
Once you’ve dealt with Heartbleed, how do you prevent it recurring?.
Summary and lead-in:
You've got rid of Heartbleed, and you're relaxing with a soothing cup of something strong, but how do you know that it's gone for good? Dominic Wellington looks at creating a containment policy for Heartbleed and for any subsequent nasty bug that will stop them from coming back to plague you again.
Feedback welcome!
The worst part is, in both cases you may end up trapping yourself on a local optimum. It's hard to abandon these maxima and cross the valley to the higher peaks, no matter how attractive they look.
It doesn't get easier over time, though. Start thinking holistically now. Talk to your peers in different teams. Better yet, talk to your users. They'll tell you what they need.
One of the things that make it most frustrating to use the web from an iPhone is form inputs. Reading the content is generally doable - and if not, there's always Instapaper. But form inputs are always a pain. Partly this is because they're over-styled, so you get stuck with fields that are either tiny or huge. Sure, testing that sort of stuff gets annoying fast. What about the stuff that is easy to do right, though?
One of the things the iPhone does is to show the user a different keyboard depending on the context. If the entry point is in an email address, the keyboard shows characters that are used in email addresses - the @ mark, dashes and underscores, and so on - instead of the space. If it's a phone number, you get a numeric keypad. This makes life much easier.
All of this is driven by the type of the HTML input
element. Set it to email
, tel
or whatever, and let iOS do its thing. But no, nobody bothers to set their input element type, so iPhone users are switching back and forth, hunting and pecking, and all the time hating web developers so very, very much.
And that's just one tip for this useful list of
8 HTML Elements You’re Not Using (and Should Be). Go, and do ye likewise.