Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • Circular Arguments Need Research

    Circular Arguments Need Research

    There’s something I hate about the fact that they charge for tampons and pads in bathrooms. I understand the financial outlay of providing a ‘service’ but at the same time, the collection method means that most of us never use them. After all, on those occasions when a woman needs a tampon or pad from those machines right bloody now, we probably don’t have our purses with us. Most women I know keep at least one in there for just such a moment, after all. If we don’t have our purses, guess what else we don’t have? A dime! In my experience, any time any woman has stared at that machine with a look of hopelessness and despair over their lack of a dime, another woman has brandished her personal emergency tampon and handed it over without a second thought.

    So why do they charge? Well if they didn’t charge, then people would just take them and that would be a financial loss. I get that. Except, as my friend Mark Jaquith put it:

    Financial outlay is an imprecise way of validating the intensity of a need.

    The day I had my great-tampon-rant was the same day I’d argued with some folks about marketing. Someone who is a ‘known’ person in the WordPress community got a bog standard email from a hosting company. It was one of those emails that looked like it was meant to feel personal, but was really just a sales pitch about what the company was and how they worked.

    The thing about that is I’m pretty damn sure the person who got the email knew all of that already. He may have known it better than the ‘person’ who sent the email. I say ‘person’ in quotes because I’m sure it was an automated campaign set to hit up people who’d emailed or used a contact form and asked a question.

    And this bothered me.

    If the email hadn’t made an attempt to be personal, and instead just said “Hey, you used our form/emailed our service address recently. Did you get all the help you needed? Do you need to talk?” I would have been just fine with it. And if he’d checked a box to say “Please contact me about stuff!” I’d similarly say “Well you deserved that one, B.”

    The reality is that he filled in a form to get a ‘report’ that he wanted to read and got that personalized email within an hour. The company offered something for ‘free’ but the cost really was data collection. Furthermore, the penalization was immediate solicitation.

    It doesn’t matter who the company is. This could be mine (it’s not) or yours (it might be). Pretty much every company known to humanity has done this at least once. And every company uses the justifications that the marketing strategy converts people into sales, and thus it’s fine. We all accept that marketing automation is hard, that identifying people we should be reaching out to and separating them from the ones who will just be annoyed by our hard sells is extremely difficult.

    Remember what Mark said?

    Financial outlay is an imprecise way of validating the intensity of a need.

    Not enough women using the pay-for tampons and pads is (part of) why they’re never going to be free. Women don’t use them because they’re pay-for (and we rarely have the damned dime).

    The ‘need’ of tampons is not being correctly measured.

    With those marketing emails, I would say this:

    Financial boons are an imprecise way of validating the effects of a campaign.

    Yes, I’m aware I just said that “Making money doesn’t mean your campaign was successful.”

    Except that’s not what I’m saying. What I’m saying is that the effects of your marketing are more than just financial. If you send out 1000 emails and get 1 sale, that sounds like ‘free money.’ Very little output and work nets you money. Everyone wants this. The problem is how many people did you chase away? What net negative are you creating? We’re not tracking the information in a way that lets us know this. We’re just thinking that any news, any discussion, and any income means it was good and effective.

    Let me ask this differently. How many auto-play ads have you seen on a website that made you like a product less? How many websites have you quit visiting because you can’t stand their ad practices?

    Not all press is good press. Forbes recently had a snafu where they asked you to turn off adblocking only to serve up ads with malware. They had a rather immediate and vocal negative impact. I doubt that level of embarrassment and pain will hit this company, but at the same time, we should be looking towards other, better ways of attracting new customers.

    This Can Be Fixed

    Looking at the situation that led to this in the first place, requiring an email to download a report is an obvious ploy to gain a list of people to contact. There was no attempt to opt in and no information that the email would be used for marketing. Step one is to disclose that. Step two is to actually make that opt-in. Step three is to provide some additional reward. “Do you like reports? Click here and we’ll send you our next one right away!” Then when you send those next reports, you can put a little footer for sales. “Interested in our stuff?”

    Step four is the hardest. Curate the damned list. Remove all your customers. You already have their emails, you don’t need to email them about your services. Put them to the side. Next you want to remove people with emails like support or webmaster. In addition, you’ll want to check your list for people who already know about your product. WordPress is an incredibly small community. There are some people who just are not ever going to be your target audience, who aren’t going to need that sale, and you don’t need to bother them. They’re also the ones who will uncheck the marketing email, of course, but just in case…

    Step five is handling your existing customers (the ones you removed in step four). Put them on separate list to target with different emails. “Hey, you’re already our customer and we noticed you liked X. Would you be interested in Y and Z?” Of course if your customers have checked that box to say “Don’t email me with marketing stuff” then you damn well better respect it.

    For step six I want everyone to stop pretending these are personal emails. Shut up. Give up. We know, okay? We absolutely, 100%, without a doubt know that you automated this stuff. And that’s totally okay. But you cannot claim personal emails, from real people, while not vetting the people to whom you’re sending email in the first place. Okay? Good. Now go be quirky! “Hi Mika! I set up our robots to email people who downloaded X because I wanted to make sure they knew about Z and Y! Hate these emails? Click here and we’ll delete you from the database.”

    But Can It Be Automated?

    Not entirely. No. The real question is ‘Should it be automated?’

    This goes back to Forbes. They automated their ads. They set it and let it run without review. Obviously the answer there is ‘No, that should not have been automated.’ It’s easier to ignore them and trust the ad company. That said, regularly I go through the ads on my site and delete them when I find them annoying or offensive. Yes, I curate my ads. And if someone tells me “Hey there was an ad for porn” I go look for it!

    As much as we’d love to automate these things, we can’t. We just need a human taking a look now and then to go “Hang on…” Marketing cannot be set it and forget it. We have to look at the return on investment. We have to understand what impact, true impact, our campaigns have. We can’t just look at the net income, we have to be aware of the seemingly invisible loss.

    And as for those tampons? We need a better metric than just “Well some people pay for them, but not enough to make us think a lot of women will use them if we give them away for free….” Maybe they could just have a nice box of tampons and pads in every stall, where you can press a lever and one item falls out every X minutes. Or maybe that idea of a drop of menstrual blood works in place of a dime… At any rate. The point is assuming things as successful because of a lack of response does not actually mean they are.

    The circular arguments, that silence proves success, or at least an acceptable status quo, need to be thrown out on their ears.

  • Mailbag: Access and Security

    Mailbag: Access and Security

    In the midst of a longer set of forum posts about how to not have a plugin updated because you’ve made edits to the plugin, someone said that their issue was that the people on the site updated.

    Now please don’t say that we should give them minimum privileges …

    Actually. That’s precisely what I’m going to say.

    1) Do not make anyone an admin whom you do not explicitly trust.

    2) As the admin, test all plugins before updating.

    3) If a plugin is constantly releasing unstable updates, stop using the plugin and look for alternatives.

    3a) But make sure it’s not your theme or a conflict with another plugin first. It may be something else’s fault.

    4) Stop editing plugins directly.

    5) Treat every upgrade as a serious thing.

    Now. I know why the guy doesn’t want to hear “You’re doing it wrong.” But the truth is this. If you give people who are irresponsible enough to update things the ability to update things, they’re gonna update things!

    True story? On one of our company sites, one of the guys has access to update all the things. He did and broke the site. I jumped in, told him “Don’t do that, please, ask me next time.” and I fixed it. And then I went through everyone who had admin access and locked their accounts down to Editors. The exceptions were the people who legitimently needed that access.

    And yes, WordPress needs more granular user roles/controls. I want that user to have access to administer all posts and add new users. I don’t want him anywhere near the plugins and themes. But I evaluated the risk vs reward of his access, and since he’s educatable, I felt it was safe to leave him there. Plus he knows right away to call me if he breaks things.

    That goes back to the trust aspect, though. I trust him.

    Trusting people to have access to aspects of your site reflect your understanding of what that access means. Making everyone and their brother an admin is reckless, not to sugar coat the situation. Only people who must be admins should have admin access. It’s really that simple. And if you insist there’s no other way around it, then you’re not paying attention closely enough.

    Make a list of what your users need to do. Not what they want, what they need. And be serious here. Do they need to update plugins or do you do it for them in a reasonable timeframe? Do they really need to be able to add users? Remember though, we’re asking what they need, not you. Go to WordPress’ list of Roles and Capabilities and take note of what they actually can do.

    Now I said before, the roles and controls and capabilities of WordPress leave a lot to be desired. But thankfully WordPress has add_cap and you can adjust roles.

    Here’s how Isabel Castillo did it:

    function isa_editor_manage_users() {
 
    if ( get_option( 'isa_add_cap_editor_once' ) != 'done' ) {
     
        // let editor manage users
 
        $edit_editor = get_role('editor'); // Get the user role
        $edit_editor->add_cap('edit_users');
        $edit_editor->add_cap('list_users');
        $edit_editor->add_cap('promote_users');
        $edit_editor->add_cap('create_users');
        $edit_editor->add_cap('add_users');
        $edit_editor->add_cap('delete_users');
 
        update_option( 'isa_add_cap_editor_once', 'done' );
    }
 
}
add_action( 'init', 'isa_editor_manage_users' );

    You only need to do that once since the roles and caps are locked into the database (see above, the controls need to be better). Still. Now your editors can edit users. Brilliant.

    So yes. I will tell you you’re doing it wrong, especially when you’re doing it in a way that is dangerous and risky in the long run.

    Don’t let the toddlers try to drive the car.

  • The Fiscal Responsibility of 25%

    The Fiscal Responsibility of 25%

    “We’re going to deploy on December 20th.”

    I winced.

    I’m not Christian and December 25th is just another day when I binge watch Netflix. The 24th? Movie night! But I picked up a habit at the Bank and that was not deploying code for the last two weeks and first two weeks of the year unless the company was going to be fined if we didn’t.

    I was brutal about that to people. I was harsh and mean and demanded lengthy justifications. I made them speak to senior management, who were hard to find around that time of year because every one was on vacation.

    The reason for this was that the bank had a clear cut fiscal responsibility not to go down between Thanksgiving and a bit after New Years. That was when year end processing happened, and that was when many companies who used us were processing the most orders. For a lot of people, business booms right when everyone wants to take a break to be with their family.

    WordPress runs 25% of the Internet.

    We use it for blogging, for building Facebook-eqsue sites, for running ecommerce stores.

    That means and we the developers of WordPress now have a responsibility not to break when we upgrade people. A huge responsibility. And it’s one we can never give with 100% assurance because of one simple fact.

    We made WordPress open.

    Anyone can make a theme or plugin. And while we do our best to test with core WordPress, we cannot test all of the 45k plugins in the repository yet. The best is maybe we could write a script to check for fatal errors on activation. But even then, can we test all 45,000 against all possible permutations of combinations?

    That’s an incredibly massive number. All my factorial calculators, even Google, just said ‘Infinity.’ And we add about 9000 plugins a year. This is staggeringly huge and it gets bigger every year

    But with this increase in share and use comes an incredible responsibility to 25% of the web. We cannot break their sites.

    Of course I know that’s impossible. There will always be outliers. And even with the large user base that companies like Yoast have, the dearth of willing and capable Beta Testers for a free product is going to bite us. It’s part of what I asked what I did at the Town Hall at WCUS — Are we going too fast?

    Speed cannot exclude us from a responsibility to our users. And with the increasing provenance of online stories and websites for everyone, pushing a change when we know that the majority of the world is celebrating something between Nov 15th and January 15th is reckless. Look at how many people want time off in those months to be with family. Look at how many businesses are running sales. Look at the amount of data transfer that spikes.

    And then picture what happens when an update has a small bug that takes down one site in a thousand. 1/1000 of 1/4th of the entire Internet. If that didn’t make you shiver, do the math again. Imagine if Apple went down because they pushed an update right around Christmas?

    The answers change sometimes, though. What if it was a security fix? Would that change your mind? It would change mine. A major upgrade around Christmas worries me. A minor one, not so much.

    It may be time to call a year end moratorium on updates to our systems and apps. If they’re business and mission critical, test them as best you can, but consider if you have to update before that Christmas rush. Make people jump through hoops to prove they need the new shiny right now. If you know you’re understaffed or under heavy load, consider that as much as anything else.

  • Consenting to Collection

    Consenting to Collection

    Collecting information on users is something every program wants to do. Doing it is easier said than done. (more…)

  • Disclosure

    Disclosure

    One of the myriad reasons I push back on WordPress plugins is because someone didn’t disclose enough information about ‘phoning home.’ Phoning Home is simple concept that comes down to this “Don’t send data from the plugin users back to yourself (or anyone else), unless you’re a service. And if you are a service, make this clear in the readme.”

    Simple, right? It’s totally easy to understand that we want you to tell people “Hey, if you use this plugin, it will report back to my servers…” Much of the time, this is obvious. A Facebook connection plugin, logically, contacts Facebook. Embedding YouTube playlists contacts YouTube. Those sorts of things we don’t worry about, though if you have your plugin say “This will pull data from YouTube” then it’s better. Sometimes this is less obvious, like if you use geoplugin.net to determine locations. Your plugin probably has nothing to do with that domain, but you still have to tell people about it so they know.

    But why do they need to know?

    First of all, this is the basic email I’ll send you if I see you’re not explaining the phone-home in your plugin:

    Plugins that send data to other servers, call js from other servers, and/or require passwords and APIs to function are required to have a full and complete Readme so we can make sure you’re providing the users with all the information they need before they install your plugin. Our goal with this is to make sure everyone knows what they’re installing and what they need to do before they install it. No surprises.

    This is especially important if your plugin is making calls back to your own servers. For the most part, we do not permit offloading of images or code, however in the case where you are providing a service (like Disqus or Akismet or Twitter), we permit it. The catch is you have to actually explain this to the layman in your read me, so they know where data is going.

    Clearly there are some basic reasons, like we should know where our data is going for our own safety. There are also some surprising reasons to people who don’t think about these things, like legal ones. You’re calling out to other servers? What if my company legally can’t do business with them? Then we have the tin-foil hat reasons, like I don’t want to do business with Google so I don’t want to have Google JS in my plugin.

    All that sounds pretty basic. And some of it is super obvious. If you’re making an app to communicate with Facebook, then it’s logically going to send data to Facebook. None of that surprises anyone, nor should it. With a service, one simply has to be up front about what the product does, what services it connects to, and why.

    “This plugin pushes your comments from your Facebook page to your blog, matching users by email addresses with their Facebook accounts (if found).”

    I just made that up. But it’s upfront, it’s honest, it’s direct, and it’s clear what’s being sent and where and why.

    There’s another aspect to this, however, something that is far trickier and more complex. What happens when your existing tool adds a service?

    The obvious answer is that you need to disclose this change to our users. As long as the users know what they’re getting into, then you are golden. The complex answer, the one I can’t really tell you a one perfect answer for, is how you might do this.

    Why is this hard? It’s hard because there is no one right way to tell users about the change. There is no one perfect way to make sure users read the information. There is no one way to get all the data to all the people who need to know about the information.

    And there sure as hell isn’t one way to make sure no one will complain about any of that.

    When you make a change to the paradigm of what your tool does, taking a stand alone tool and adding in a service, you have to consider that a percentage of your users will rebel. This is simply because all those wonderful things you do about disclosing the service for new users have to be transitioned in a meaningful and logical way to existing users. And there is just no way to do that perfectly.

    This doesn’t mean you shouldn’t try. This means you have to be creative and innovation and a little ‘in your face’ about the change. You have to give users an option, before the service kicks in, to say if they want their data shared.

  • Mailbag: Wasting Time

    Mailbag: Wasting Time

    Today’s question comes from a Slack DM tossed my way about learning and possibly discarding Jekyll.

    Don’t you think you’re wasting your time learning all these nonWordPress things?

    Nope! Every single thing I’ve learned and discarded has improved my skill set.

    Let’s take MediaWiki. Learning that taught me templating in a way that I never would have understood in WordPress. It also taught me about the perils of your ‘own’ language instead of HTML. While I’ve come to like Markdown, you still have to know HTML to make Markdown really work, because you need to understand what it is you’re writing.

    And Jekyll? I learned a lot about importing and exporting data between ‘languages’ that don’t like each other. I also learned a lot about deployment of static content. Anything but FTP, right? Jekyll had me writing my own deployment scripts.

    Now that I’m looking at Hugo, really not much has changed. I’ve learned GoLang, which is not all that different from things I already knew. But it’s expanding how I think about the logic structures. Hugo’s got an up on Jekyll in a lot of ways, like how easy it is to make loops for traditional blogs. Also it can handle remote JSON a little better, which sets me up for what’s next.

    You see, all of this work, all this learning, is going to come back to WordPress.

    What I want to do is manage my site in WordPress and have that output the JSON (via that awesome new JSON API I’ve been learning), which will in turn be dynamically called when I want to build my static HTML site.

    For sites you’re not updating daily, or even weekly, this might be the magic you need. Everyone writes on WordPress. Someone has a command (or even a script) to run that collects everything from JSON and dumps it to Hugo, which generates the site for you to proof and then push.

    Version controlling the content.

    Let the users write in Wordpress while you bask in the glory of your static site that is, pretty much, unhackable as a CMS. I mean… what are you going to do to my HTML?

    See?

    It’s all WordPress.