68 stories

Italian Company Calls Itself ‘Steve Jobs’

1 Comment

Chaim Gartenberg, writing for The Verge:

After years of legal battles, a pair of brothers — Vincenzo and Giacomo Barbato — have successfully managed to win a legal battle against Apple, earning the right to call their company “Steve Jobs,” after Apple’s iconic founder, according to la Repubblica Napoli.

The fight began back in in 2012, when the two brothers noticed that Apple had never trademarked Jobs’ name. The pair were already in the process of starting their own clothing and accessory company, after spending years creating products for other brands, and decided that “Steve Jobs” would be the perfect name for their new brand.

I realize Gartenberg is trying to write from a neutral perspective here, but let’s face it, no one thinks they named the company “Steve Jobs” because they thought it would be a “perfect name for their new brand”. They named it “Steve Jobs” because they’re attention-seeking assholes.

Regardless what Italian trademark law says, who but an asshole would do this?

Read the whole story
55 days ago
Maybe the same sort of asshole that names their company after an already successful record label?
Sebastopol, CA
Share this story

Face ID Can’t Approve Family Purchases

1 Comment

Samuel Axon, writing for Ars Technica:

iPhone X owners have found that Face ID isn’t available as an authentication method for the “Ask to Buy” feature, which allows parents to approve their kids’ iOS purchases and downloads. Instead, the parent (or any other “family organizer,” as Apple terms it) must enter their entire Apple account password to approve each individual purchase attempt.

Users are frustrated because equivalent functionality was available on Touch ID devices, and that functionality has been lost in the transition to the iPhone X. Face ID can be used as an authentication method for other purchases, just like Touch ID before it — but Touch ID also worked for “Ask to Buy,” and Face ID doesn’t. […]

Parents of large families with several children, each of whom might have an iOS device available to them, will find that the requests mount up quite quickly — especially right after the holidays. Kids cashing in App Store gift cards add to the requests already coming in from normal use and in-app purchases in games.

I only have one kid, but I noticed this too in the post-holiday gift card bonanza. I can’t really think of a good explanation for why Touch ID can authorize these transactions but Face ID can’t.

Read the whole story
57 days ago
Really? "Hey Dad look at this!"
Sebastopol, CA
57 days ago
54 days ago
Which you can follow up by a bit of parenting and refunding the purchase.
Share this story

Me on React: an old dog with new tricks


Over the years I've been consistently uninterested in using the new slew of frameworks and libraries that have been released. By no means is this because they're bad at all, but because my particular kind of work didn't require it. However, in the last 12 months I've made significant use of React and have even released a few client projects using it. So what's changed for me? As someone who's very much "pro vanilla" and bare-metal JavaScript, why have I changed my mind so significantly?

This post really isn't for those developers out there who use tools like React daily (or Vue, Polymer, etc), but for those old dogs like me that have been resisting (for whatever reason) the new technology. Probably the old dog standardistas.

This post is written for an earlier version of me. It doesn't contain silver bullets or very much code, but hopefully it does put lay some of my previous fears to rest.

Below I've tried to outline what my original concerns were and how they've been mitigated in some way or another.

😵🔨 Overhead of tooling

This was and continues to be one of my biggest concerns when it comes to daily development. Technology is difficult enough when it moves as quickly as it does (I'm speaking in broad terms). We don't need to know everything, but it certainly helps if we're aware of everything. I remember an old project manager asking me if we should use "comet" for some software solution back around 2006 (when the concept was coined!).

So the thought of having to add some new build process to my current workflow was an initial hurdle that I really didn't want to overcome. Currently I know of grunt, gulp and webpack, but I'm 100% certain there are more tool runners and special configurations that you'll need to learn to get past the very, very first step.

Enter Create React App (henceforth known as CRA in this post). In my very first foray I tried to use CRA but got overwhelmed by the generated files, directory and config, so I aborted. Thankfully, I revisited it again a few months later, either armed with a little familiarity with React components or perhaps the config was hidden, but the big, nay huge, benefit was that the configuration is entirely hidden (though you can eject CRA and manually tune the configuration).

It meant that I could get up and running with zero configuration and I could write code and see results.

😐🖍️ A side note about styled components

As you might have guessed from my emoji title: I'm not sold. I think I understand the point of styled components, in that it will allow for the browser delivered code to include only the CSS required, but I'm still a little long in the tooth for this modern method.

In truth though, I don't know enough about the ideas behind this approach to adopt it myself. I feel (read: my gut thinks, and very little else) that styles should be kept in stylesheets and not be modified at the wim of every component that uses them. i.e. if a button style is used, it shouldn't be changed at the component level, but changed across the board of the code to consistently affect every button element. Or if it's a single "tweak" required, then it's still needed at the high level of globally accessible styles, as I've learnt over the years: it's never just once.

Bottom line though: I don't have a strong reason to use these, and I'm not entirely sure it benefits the standardista inside of me.

😭♻️ Reloading and losing state

I've posted previously about my workflow and to this day, I still use devtools for development. An important factor of using devtools is maintaining application state both for debugging but also for general development.

This means that I've interacted with my software, perhaps entered some value into a form, and when a small amount of code changes, either JavaScript or CSS or even some HTML, I do not want the state of my application to change, but only to inject and recognise the small change I've made.

The problem that I have with build tools that transpile my code to browser friendly JavaScript is that the browser quite often has to reload to recognise the newly built code. In a few examples I've tried using Angular and using System.js they both relied on a live-reload component that would reload my browser when I saved in my editor (which makes things even more confusing when the editor is devtools).

React's hot module reloading avoids this for the most part. What HMR gives me is that when a single component is changed, it is dynamically recompiled and injected into. This is an "old" (2 years) talk by Dan Abramov explaining how HMR works, in particular the core concept is explained around the 7 minute mark.

CRA has HMR turned off by default, but it doesn't require much to enable it. The index.js is changed as such:

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';

const rootEl = document.getElementById('root');

  <App />,

if (module.hot) {
  module.hot.accept('./App', () => {
    const NextApp = require('./App').default;
      <NextApp />,

Note the original source for this code is Chris Shepherd. I've also used this code for a few development projects and it works well.

Finally, this twitter thread also points to why HMR not turned on by default.

With HMR I'm able to maintain a large amount of application state when I'm making changes throughout my software.

For CSS, I do have the option to import CSS directly into React components (as you see above in the earlier example) but I'm not 100% sure why I would want to. I think it might be to encourage the component architecture in the CSS, or perhaps to do with code-splitting and component dependencies (but I again, I'm not entirely sure).

If I move the CSS to the public directory, now I'm able to map the directory in devtools and make direct changes inside of the elements and sources panels.

Hot module reloading retains a large amount of state, and putting CSS in to the static served directories means I can use devtools to manage styles.

😨📡 Server side support

I've spoken to a lot of individuals that I would call standardistas who have stories of projects being handed over to a React chopshop and server side support, SEO and all the rich goodness of a server delivering the content is thrown out the window.

My sense having spoken to more individuals is that server side rendering (SSR) is an extra mile that is often left off as not required or valued enough. This is my own finger-in-the-air opinion, please don't take it as gospel. Though I wonder if BigQuery could answer this question…

To me, a growing oldie on the web, even the phrase "server side render" makes no sense, since the server has to render. You can't get a client without the server (also see rants on "serverless" on twitter!). And why would a developer purposely lose the speed benefits of delivering a fully rendered tree to the client escaped me. The answer of course was: it's hard.

SSR is entirely possible with React and just requires a little diligence to get the work done. I've written about SSR before, but Jack Franklin has an excellent introduction to this and how to solve SSR with React.

More recently Next.js has come onto the scene which embraces SSR at it's core and takes the React framework to make "universal" JavaScript out of the box (universal being JS that can be run on both the server and the browser). It's a small mind shift when it comes to routing and directory structure, but it's frighteningly straightforward to follow a few of the examples from the documentation to get a SSR React application up and running.

Related: I've started a video course on Next.js that you can sign up to find out more about.

The Next.js Github repo includes a great deal of examples that cover different uses too, and in addition I completed a project for Brad Frost that uses Next.js to deliver the application earlier this year.

Below is an incredibly small demo of a web site that only prints the number of times the page has been loaded locally. It uses React and Next.js together, and importantly, to read the querystring from the initial request, Next provides a special getInitialProps method which is used to populate the component's properties.

// filename: pages/count.js
import { Component } from 'react';
import Link from 'next/link';

class Count extends Component {
  // getInitialProps allows my component to read the query string (amongst other properties)
  // this function will run for the very first time on the server when the user requests
  // this page (/count).
  static getInitialProps({ query }) {
    const { count = 0 } = query;

    // the object I return will be passed to my component as `props`, so now the props.count
    // property will be the value of the querystring.count (or zero as I am defaulting the value)
    return { count };

  constructor(props) {

    // inside the component, I'm actually using a state value, so that it'll change every time
    // the component receives an update - but will *always* reset back to the query string
    // value set in `getInitialProps` on a full server load
    this.state = { count: parseInt(props.count || 1, 10) };

  // this handler fires when the user clicks on the <Link> element that I rendered, which
  // is my chance to either read the count from props - which would have been re-loaded in
  // `getInitialProps` in a client side load, or if it's not present, we'll increment the
  // state value
  componentWillReceiveProps(nextProps) {
    this.setState({ count: parseInt(nextProps.count || this.state.count + 1, 10) })

  render() {
    const { count } = this.state;

    // important to note: I am wrapping my <a> elements in a <Link> element. This will
    // "enhance" the anchor so that it can load the page locally, without the round trip
    // to the server.
    return (
        <p>This page has been locally <Link href={`/count`}><a>loaded</a></Link> {count} {count > 1 ? 'times' : 'time'}.</p>
        <p>To manually change the number, use the query string: <Link href={`/count?count=${count + 1 }`}><a>?count={ count + 1 }</a></Link></p>

export default Count;

Next provides a great deal of hidden magic, including JSX support without having to include the react module, but also handles the routing (based on the pages directory) and all the rendering. Here's a Glitch that you can remix and have a play around with too.

A quick proof of concept can be seen using curl and scrapping the p element (aside: scrape is a custom tool I wrote):

$ curl https://remy-next-demo.glitch.me/count\?count\=10 | scrape p --text
This page has been locally loaded 10 times.
To manually change the number, use the query string: ?count=11

This shows that the server isn't just sending an empty body tag and indeed rendering on the server fist.

Server side support does come at a price, but is not particularly harder than the client side react logic. Using Next it comes for free, but (again) at the price of a much higher abstraction.

😟 Overcoming trade-offs

There's a handful of trade-offs that I've personally noticed or I bump into regularly. The first, that will affect every author using a library or framework to some level of degree: abstraction.

Abstractions everywhere

I remember when I was starting out with jQuery (pre 1.0) and I'd often refer to the result of the foo = $('div') expression as "an array-like object". I knew that I could access foo[0] and it would give me the first element, like an array, and I could access foo.length, like an array, but it wasn't an array.

It was only until I had read through and understood a decent portion of jQuery's source code did I understand that it was borrowing the array push method to push elements into an object. Or why modifying jQuery.fn.plugin = bar would upgrade all jQuery instances.

Abstraction is everywhere, so I believe you either have to accept that you don't fully understand what's going on under the hood (this is how I feel about Next.js right now, because I've not reviewed any of the source), or you do a little research to understand how the fundamentals work.

For me, reading this post was an excellent resource. Also some reading or videos (sorry, no good links) about the Virtual DOM helps a great deal.

What stacktraces?

I've had mixed experience with stacktraces and React. In fact, the current version of CRA comes with a really good error reporting system that gives me both the source trace (which is often useless to me), but also offers a mapped trace (showing my original code), and rather magically clicking on the line will jump open to Sublime in the file and line in question. All this is overlaid in the browser window and can be dismissed if I want to ignore the error and continue with the app.

However, I've also experienced the version of reporting that's so abstracted from my code and original source that the only clues I have to the location of the error is by asking myself: what did I just change? Frustratingly Next.js (at present) suffers from this in my experience with it.

I'd also say, if I didn't have CRA to build my initial setup, I'd likely be in a mess of abstracted stacktraces.

Sadly I've had poor experience of error reporting in production. Sourcemaps seem to never really help me, and I'm left attempting to diagnose issues based on a hot mess of useless traces. I expect that this is another learning curve or tool or something that I need to discover.

All in all, it's not absolutely terrible, but for me, that's entirely down to CRA.

All the scaffolding

As a one person shop, this comes off as slightly tedious having to create a container, then a component, but I can see the benefit when sharing code with others, specifically: having a shared dialect as to how code is structured and arranged

A perceived forced structure, "finding the react way of doing things" - though I suspect all frameworks suffer from this, and there's some degree in which you can bend the rules

😍 Wins

This article has a number of frustrations that I've overcome, though it's more to reassure you, my dear reader, that the landscape really isn't as hard as I had expected.

However there's some really nice wins that come with React (and I honestly suspect this is the case with other frameworks and modern libraries available today).

I've outlined a few and included why they're important to me.

Real components

The component system that React relies on naturally puts your code into small modules designed to do a single thing. This approach has long been my aim in development, but always tricky to pull off consistently across projects.

Boilerplate aside, the most of the single files in projects I've worked on are about two scroll heights of my editor. What's important about this is that it makes debugging, testing and upgrading much easier since there's less moving parts in a single file.

Components can pull in other components and so on and the architecture organises itself in a sensible and pleasant to work with way.


Components lead nicely to structure of files. Another thing that I've personally found hard to consistently carry across different projects. Except with React. There's a number of patterns that dictate what a directory will be called (though not enforced). I recently completed a Next based project, and one of the most pleasing aspect as developer was the final directory structure.

Anything that helps me to create a consistent and replicable project structure is extremely valuable.

State machine

One of the more popular state machine libraries for React is Redux (based around Flux, though I've personally never used Flux).

I got hooked on the idea of state machines in software way back in my university days (the late 90s), then again with a talk at jQuery UK 2013 by Doug Neiner. Then after 30 minutes of watching Dan Abramov egghead (free) video tutorials on how Redux works, I was hooked 100%.

I'm a huge fan of state machines because they make developing, debugging and testing a lot simpler. This is because instead of relying on any number and combinations of user input to set my application to a specific state, I'm able to manually set the state and inject it into my system to see how it behaves (and make any necessary changes there and then).

There's a huge ecosystem around React which means there's going to be more wins to be found. One of the next items I'd like to try out Storybook which promises to let me build and design components in isolation (whereas before I was putting them individually into test pages).

Hopefully this was useful for one or two of you. Feel free to shoot me any questions you might have in the comments or as a blog post and I'll do my best to share my experience.

Originally published on Remy Sharp's b:log

Read the whole story
191 days ago
Sebastopol, CA
Share this story

The Four Donald Trumps You Meet On Earth

2 Comments and 6 Shares

Donald Trump has said repugnant, insulting things about women—over and over and over again—for as long as he’s been in the public eye. He has called various women crazy, flat-chested, pigs. He refers to them as “pieces of ass.” He said pumping breast milk was “disgusting.”

“Women,” he told New York magazine in 1992. “You have to treat them like shit.”

Trump’s misogyny is shocking because it’s so brazen, but it’s infuriating because it’s so familiar. Chances are, if you’re a woman in 2016, you’ve heard it all before.

* * *

The first time you meet Donald Trump, he’s an older male relative who smells like cigarettes and asks when you are going to lose that weight. You’re nine years old. Your parents have to go out and buy a bottle of vodka for him before he arrives. His name is Dick. No, really, it is. At dinner one night, he explains to you that black people are dangerous. “If you turn around, they’ll put a knife in your back.” Except Bill Cosby. “He’s one of the good ones.” Turns out he’s wrong about Cosby and everything else, but the statute of limitations on Dick’s existence on Earth will run out before that information is widely available.

The next time you meet Donald Trump you’re in high school. You’re on the Academic Decathlon team because those are the kinds of extracurriculars a nerd like you gets down with. Model U.N., Thespians, Scholar Quiz, getting those good report cards with no boyfriends anywhere, girl! The teacher who’s volunteered to cover the Lit portion of the Decathlon is also the tennis coach, and he’s going over Ezra Pound’s poem, “Portrait d’une Femme,” with you and your teammates. He’s the first person who looks at you a certain way that will happen again and again for the rest of your life, as if he simultaneously can’t see you and would like to kill you. He tells you the woman in the poem is “clearly a prostitute;” which is very, very wrong.  You explain to him that this part…

Your mind and you are our Sargasso Sea,

     London has swept about you this score years

And bright ships left you this or that in fee:

     Ideas, old gossip, oddments of all things,

Strange spars of knowledge and dimmed wares of price.

…doesn’t mean that men literally pay her. Sure, she’s someone stuck in a time when she can have nothing of her own; someone who assembles her life from the odd bits she collects from others, choosing a catch-all existence over a suffocating marriage—made second-rate perhaps by her time, not by her self—but the “fee” doesn’t mean she is being paid for sex. He tells you that you just don’t get it. What he doesn’t get is that she’s a person. He is aging and bald and enjoys saying “whore” to a roomful of children. A few years later, he gets fired for having sex with a student. Him? Him. Of course him.

The next time you meet Donald Trump, he’s your boss. Well, he’s your boss’s boss. A vice president in marketing who seemingly literally cannot stop talking. He’s on his third wife, and that’ll be over in a few years. He can’t believe your mother is his age. He thinks you are friends. He asks you if you’ve changed your hair every time he sees you. Sometimes during meetings he’ll turn away and open a magazine while someone is presenting. One time he comes to a halt in the middle of his own sentence to stare at a woman’s boobs for somewhere from seven to 27 uncomfortable seconds. (It’s hard to gauge time accurately during a truly aggressive boob-stare.) When he finally gets fired years later, his HR file as fat as a pig knuckle, the rumor is he’s caught stealing his own office furniture on the weekend. They don’t even stop him. They just let him go. It’s like the building itself sighs with relief.

And then you get out of your more corporate job and become a television comedy writer on a good show, a show that keeps going. You go from staff writer to producer to co-executive producer in the space of seven years. You work with your sister, which is like a dream, and your co-workers are cool, and your boss is very, very cool. It’s almost as if the fact that you’re a woman doesn’t matter at all. At all. It’s like you finally escaped.

The Trumps are vanquished. They’re dead, or arrested, or fired, sobbing quietly into their stolen office furniture, wondering where it all went.

But then, it starts happening. The actual Trump—the real Donald Trump—starts making a bunch of noise about the birth certificate of a black man. It’s racist. It’s so racist. But it’s just background noise. Then he starts winning in the primaries. You say “no fucking way,” under your breath a lot when you read the headlines.

There he is, implying that people of color are dangerous, that women are whores, that you just don’t get it, opening a magazine while someone else is talking. There he is, all the worst people you ever had to meet, and tolerate, and fight, or at least ignore. There is the villain at the end of the horror movie rising up again with his knife and you are like: “This motherfucker again? No way, I’m tired.”

And it makes you deranged, like almost actually deranged. You engage his followers on Twitter for awhile and then decide to just tweet fart sounds at them because arguing with them is pointless. They think there is actually a discussion to be had about whether racism is okay.

You can’t believe these people and you can’t believe this guy, Donald Trump. It makes you insane to look at him, to see that look on his face that you’ve seen before when he talks about women who aren’t supermodels. When he talks about black people, or Mexicans, like he simultaneously can’t see them and wants to kill them.

And then you write a tweet about how Donald Trump is making you a loon because you’ve had to deal with him over and over again in your life, and someone from The Atlantic asks you to write a personal essay about it. You don’t write essays, you write fart jokes, but you give it a try. You write it in second person, which is a kind of writing that you are pretty sure people look down on, but screw it, you’re old now, and you’ve got money in the bank and kids and you are too tired to care what anybody thinks about your second-person narrative voice. “Who cares what readers of The Atlantic think about my second-person narrative voice,” you whisper to your cats, while secretly deeply caring.

Screw it because you aren’t that lady in that poem whom Ezra Pound can only see as a collecting bin for dribs and drabs left by men. You’ve got money and a job. You made yourself. All those other Trumps are dead, or fired, or pleaded no contest to the charge of sex with a minor, or all of the above. Because they are disasters. (Hell, even Ezra Pound wound up in an open-air cage because he was an anti-Semite and fascist sympathizer.)

Hillary’s still ahead in the polls and she looks like a comer. You bought a house in the Valley with your own dough where you found the exoskeleton of a praying mantis in the yard this morning and placed it in a Tupperware for safekeeping. An artifact, an old skin.

“There’s no one like him,” people say, “He’s unprecedented.” Maybe so, but I swear I’ve been dealing with this douchebag all my life, and let me tell you something: It doesn’t end well for him.

Because black people aren’t dangerous, and because their lives matter; because not every woman is a prostitute; and honestly because that furniture just isn’t yours, dude. The world is always watching, and you can’t get away with it forever. Go ahead and slip out of your skin into a different form. We’ll fight you again, then. Go ahead.

And by the way, Dick, if you’re reading this from Ghostville, I never lost that weight, Bill Cosby is an alleged serial rapist, and Hillary Clinton will be the next president of the United States.

Read the whole story
515 days ago
Sebastopol, CA
Share this story
2 public comments
511 days ago
Fuck Donald Trump
515 days ago
“There’s no one like him,” people say, “He’s unprecedented.” Maybe so, but I swear I’ve been dealing with this douchebag all my life, and let me tell you something: It doesn’t end well for him.
Waterloo, Canada

★ Melanie Ehrenkranz and Apple’s Response to Her Criticism Over the Paucity of Women Onstage at Last Week’s Event


Melanie Ehrenkranz, writing at Mic, “Apple Responds to Diversity Criticism: ‘We Had a Canadian’ Onstage at iPhone 7 Event”:

On Friday, I published an article about the gender divide in Apple’s last two iPhone events. I pointed out that while Apple has been vocal about its commitment to diversity, this commitment is not evident in the company’s choice of keynote speakers and their stage time. On Wednesday, when Apple introduced the iPhone 7, women spoke for approximately eight minutes; men spoke for 99. Furthermore, most of the women and people of color who appeared onstage weren’t Apple representatives.

A 99-to-8 difference in stage time certainly isn’t something to be proud of, and it’s worth pointing out (and keeping track of). But last week’s ratio was so disparate not because the company didn’t pick enough women for speaking slots. Rather, it’s because the executives in charge of most of the products announced last week were men. Whoever is in charge is generally who presents. Jeff Williams runs Apple Watch. Phil Schiller, as head of product marketing, is going to present the iPhones. Jony Ive runs design.

Susan Prescott wasn’t chosen to present iWork collaboration because she’s a woman; she was chosen because she runs product marketing for iWork. Bozoma Bozama Saint John presented the Apple Music segment at the WWDC keynote because she runs marketing for Music and iTunes. Lisa Jackson was on stage in March to talk about Apple’s environmental efforts because she’s the vice president of environment, policy, and social initiatives. The people who present at Apple’s events have a real relationship/responsibility with the material they present.

So the problem is not that women are underrepresented as on stage speakers. The problem is that they are underrepresented in leadership positions. I would argue that it’s better — more honest — for Apple to allow its onstage diversity to accurately reflect its actual leadership diversity. If Apple simply put more women and people of color on stage, it would be a token gesture. If Apple puts more women and people of color on this page, more of them will appear on stage as a result.

Ahead of publication, I emailed Apple for comment twice, with no reply. After the story was published, an Apple public relations spokesperson sent me an email, saying “we may have different interpretations of diversity.” As evidence of this diversity, he pointed to “two African-Americans” who spoke at the keynote, neither of whom are actually employed by Apple. He also mentioned “a Canadian, and a British woman.”

The Apple spokesperson began the email with the words “off the record,” a condition Mic did not agree to before the statement was delivered. Apple’s PR team should be advised that off-the-record statements are “prearranged agreements” whose conditions are decided on beforehand — a longstanding rule of ethical journalism. A source’s request to speak off the record must be approved by the reporter before the off-the-record information is shared. (This is spelled out in detail in the Ethics, Law & Good Practice section of the NYU Journalism Handbook for Students, which notes that “it is essential that the reporter and source agree on a definition before beginning an ‘off the record’ portion of an interview.”)

Abiding by standard journalism practice as well as Mic’s editorial standards, the email is, in fact, on the record. We’ve published it below.

Publishing this email may well be technically within the letter of the accepted rules of journalism. But it strikes me as a dick move, unless the email contains something newsworthy enough to warrant it — and this email did not. Sending the email beginning with “Off the record” and then including the message is based on an assumption of courtesy and trust. What this Apple PR rep1 could have done is first email with “Off the record?”, wait for Ehrenkranz to reply, and if she agreed, send the actual message.

But here’s the thing: I think the email from Apple is quite reasonable. It’s not great, and should have been much better, but publishing the full email makes Ehrenkranz look like a sensationalist jerk far more than it makes Apple look indifferent to the company’s diversity issues.

Apple’s rep wrote:

“There was a lot of diversity on that stage that you don’t recognize. Unrecognized by you was the fact that we had a gay man, two African-Americans (Instagram and Nike), a Canadian, and a British woman, Hannah Catmur.”

From that, Ehrenkranz and Mic.com chose to run the headline: “Apple Responds to Diversity Criticism: ‘We Had a Canadian’ Onstage at iPhone 7 Event”. As I’ve written recently, headlines matter. This headline is egregious.

No reasonable person could say that Mic’s headline is an accurate categorization of Apple’s response. Even worse, the quoted text in the headline — “We Had a Canadian” — is not an actual quote from the email.2 Even if you disagree with Apple’s response — it should have been handled much better than it was — it’s clickbait journalism at its worst to imply that Apple’s response to criticism that there weren’t enough women on stage was, quote, “We had a Canadian”. It’s not merely grossly inaccurate, it’s implying utter callousness regarding a serious issue.

The first thing Apple’s rep actually said after “We had a” was “gay man”. The paucity of women and people of color in Apple’s leadership are real problems. But it’s like it doesn’t even count that Tim Cook, proudly and openly gay, is the primary face of the company.

  1. It’s completely unclear to me why Ehrenkranz felt free to publish the entire email but omitted the rep’s name. ↩︎

  2. They could have gone with “We had … a Canadian” and technically argued that it was a legitimate edited quote, but it still would have been a grossly inaccurate truncation of the response. And given all of Ehrenkranz’s insistence that NYU’s Journalism Handbook for Students allow for the publication of the email, despite the request that it be “off the record”, that same rulebook makes clear that diddling with a quotation is verboten↩︎︎ response.” ↩︎︎

Read the whole story
527 days ago
The grid of middle aged white men is still an issue
Sebastopol, CA
Share this story
3 public comments
526 days ago
The irony of citing an ethics handbook to publish an email while presenting something that wasn't ever said as a quote. I didn't check the handbook but surely there's a chapter on quoting?
527 days ago
Journalistic ethics FTL
527 days ago
I really dislike the "it's not what you said, it's how you said it" argument when responding to someone.

I like your protest but, you're not protesting right. I like your opinion but, you didn't state it right.

The presumption is not that a person agrees/disagrees with the point but, rather the person doesn't accept the point because it wasn't presented in a way the person wanted it presented.

Apple Drops ‘Store’ From Apple Store Branding

1 Comment

Juli Clover, reporting for MacRumors:

Apple appears to be making a slight branding change to its retail business, dropping the “Store” moniker when referring to its Apple Store locations. Apple has already made the change online, and all of its store pages now refer to stores by names like “Apple Union Square” or “Apple Valley Fair” or “Apple The Grove,” instead of “Apple Store, Valley Fair” or “Apple Store, The Grove.”

It’s a change that appears to have started rolling out with the launch of the newer Apple Stores, like the Union Square location in San Francisco. Apple has always referred to that store as just Apple Union Square, and over the course of the last few days, the company has updated all of its retail store webpages to remove the “Store” branding. What was once “Apple Store, Fifth Avenue,” for example, is now just “Apple Fifth Avenue.”

The “Store” branding only made sense when the concept was novel. Now that Apple’s stores are well established, it makes sense to drop the “Store”. Think about the brands that are Apple’s peers in retail. No one goes to the Tiffany Store or Gucci Store, they just go to Tiffany or Gucci. It’s not even just a premium thing — you say Target and Walmart, not Target Store and Walmart Store.

Read the whole story
551 days ago
Biggest deal for employees. They no longer work for an Apple Store but just for Apple which sounds small but changes the feeling a lot
Sebastopol, CA
Share this story
Next Page of Stories