In episode 37, we dive into some of our recent work with making changes to UIs, how our expectations for UI influence our experience, and some initial thoughts and results on some pricing experiments.
This episode was sponsored by WP Ninjas, the creators of Ninja Demo and the highly popular Ninja Forms plugin.
Show Notes:
Caldera Forms review
Startup podcast
Review us on iTunes
Transcript
INTRO: Welcome to Apply Filters, the podcast all about WordPress development. Now here’s your hosts, Pippin Williamson and Brad Touesnard.
BRAD: Welcome to Episode 37. Today, Pippin and I will be talking about what we’ve been up to and lots of user interface stuff.
PIPPIN: Once again, Ninja Forms, the guys from WP Ninjas, have been kind enough to continue to sponsor us. They’ve had a couple of new extensions released recently. They released a Slack integration that lets you send notifications to your Slack chat room when a form is submitted. They also released a GetResponse and iContact integrations recently for email lists, so doing some really cool stuff over there. Go check them out at NinjaForms.com and WPNinjas.com.
You have been working on expanding your team recently, once again. It seems like this is a pretty consistent trend.
BRAD: Yeah. We’re kind of perpetually —
PIPPIN: Tell us about it.
BRAD: Perpetually hiring over here. No, we’ve had a fellow named Jeff Gould on trial for a while now, and he’s going to be going full time with us on Monday, so we’re super excited about that. It’s going to definitely help us accelerate our timelines and whatnot. And, he’s actually based in the U.S., which, believe it or not, is the first U.S.-based team member for us.
PIPPIN: Out of how many members now?
BRAD: Including myself and Jeff, we’re five total now.
PIPPIN: Very cool.
BRAD: Yeah, it’s pretty exciting. Then also he was actually working on a nice feature that’s going to be coming in Migrate DB Pro in the next release. I’ve mentioned this before on the show that we’ve been having trouble with some hosts blocking our requests because we’re making requests too close together. We’ll make one, and then, a second later we’ll make another request.
PIPPIN: Sure.
BRAD: It’s kind of how our migrations work. He added a little control on the settings tab where you can just slide it up and add one-, two-, or three-second delay between the requests.
PIPPIN: It slows the migration process, but it also keeps hosts from blocking it.
BRAD: Yes, yes. We actually considered; we had a debate about whether or not we should just do it by default. We should set it to, like, two seconds by default just so most people will never run into that issue.
PIPPIN: Sure.
BRAD: I did a little bit of testing, and it actually slowed the migration I tried down by 3X, adding a two-second delay.
PIPPIN: Wow. That reminds me of a really interesting statement I heard from some developers or researchers at Facebook once. Facebook obviously has really, really good servers and is consistently very fast. I was listening to, I think it was, an interview with one of their database designers or something, somebody like that. He was talking about request speed and how it doesn’t necessarily matter how fast the request speed it. Obviously, to a degree it matters.
What matters more is consistency. If it’s consistently 500 milliseconds to load a page on Facebook, that’s okay as long as it’s always 500 milliseconds. If one day something jumps up and is 2,000 milliseconds to load a page, it throws people off, which makes me think that always slowing it down may not be such a bad thing.
You noticed that it was slower for you, obviously, because you intentionally delayed it. But that makes me wonder if you did that, aside from people that experienced the older version and the new version, would anyone notice.
BRAD: Y
