Search This Site
Silicon Valley veteran doing Technical Community Management. Photographer with a strong interest in birds, wildlife and nature who is exploring the Western states and working to tell you the stories of the special places I've found.
Author and Blogger. They are not the same thing. Sports occasionally spoken here, especially hockey. Veteran of Sun, Apple, Palm, HP and now Infoblox, plus some you've never heard of. They didn't kill me, they made me better.
Person with opinions, and not afraid to share them. Debate team in high school and college; bet that's a surprise.
Support This Site
If you found this page interesting, please consider clicking through this ad and buying something.
If you do, Amazon will pay me a small percentage of the price. You don't spend any more on the item, and the money helps pay for the site and the more people who do this the more time I'll be able to spend on the site improving it and adding content.
More to Read
- Some Thoughts on Lightroom Keywords
- How not to be a doofus with a camera
- Beyond 'Vacation Snaps'
- A teachable moment (or why I love birding, even when I make a fool of myself)
- Sherman, set the wayback machine to…
- An audience of one....
- Talking about 'Stuff'
- What I do for a living…
- 50 reasons Why I Haven’t Been Blogging
Want more? Try this list...
New on the Blog
- The new flickr design
- Yosemite Road Trip 2013 – Day 1, teaching.
- The Raffi Torres Hit
- Tioga Pass, Yosemite
- Back from Yosemite
- Bobcat before and after
- 2013 playoffs, round 2
- Fuji X100s Review – Fallin’in Love All Over Again
- If you give them an easy out, they’ll take it.
- Another reason Don Cherry should retire (or be retired…)
Rent Gear at Borrowlenses
Don't buy that gear before trying it out! Renting a lens you're considering buying is a great investment in saving yourself from buyer's remorse!
And if it's a piece or gear you aren't going to use constantly, renting it when you need it is a great way to save money, and I highly recommend Borrowlenses as a place to rent high quality, well-maintained gear.
Category Archives: Computers and Technology
I know some people have been wondering why Apple hasn’t updated the Mac Pro. Well, I think we know what they were waiting for…
Here at NAB, Intel just introduced the next generation of its Thunderbolt interface, which promises a data rate of 20 Gbps in both directions (on each of the two channels) as opposed to 10 Gbps for the previous version.
A couple of things I’d like to see in IOS 7
I want to see Apple release a simple password wallet and an API for apps to use to pull data from it. Something like 1Password’s baby brother. And with the API, a way for those of us who use more powerful tools (like 1Password) to connect to those via that API instead of the default App. (I would, in fact, like Apple to get in the habit of allowing us to replace their default tools with more powerful versions as a general practice. I’m not holding my breath).
And then I would like to see Apple make “secure your freaking passwords” a focus of the release and their marketing.
Remember ICE? (In Case of Emergency)?. Everyone should do some form of this on your mobile devices. Do you?
But there’s a problem. Everyone should ALSO pin-lock your mobile devices. Do you?
And if you do, how would an emergency responder get access to it? It’s behind a PIN.
So here’s my suggestion…
With IOS, when a device is pin-locked and you activate it, it brings up the Enter Passcode screen. If the device is a phone, that screen has an Emergency Call button to allow you to dial 911. I suggest Apple add another button for ICE. By default it would bring up your ID information out of the address book based on the card you’ve defined as being you.
But Apple could build a basic ICE app that if you fill out with information, and if you configure the system to use it, hitting that button would fire up that app instead. That would allow you the option of making available other information, such as insurance or drug allergies or information on existing conditions (I, for instance, don’t do well with codeine. The last time I took it, I had an extended conversation in which I solved the Middle East situation — with my wall clock; my medical record now suggests I not be given codeine).
If this interface allows the user to define ANY compatible app as the ICE app, this creates a third party opportunity; while it’d be a nice market, there would be some options here for developers to create some interesting solutions.
It would also create an opening for developers to create apps that use this capabilities for non-ICE capabilities. Some might see that as an problem because we’re circumventing the pin-code. I see it as an opportunity, since use of it is purely optional, and Apple actually set a precedent to allow that with both the emergency call button and the “quick camera” capability they added to the lock screen.
I originally suggested this around the building at Palm for webOS before the first phone shipped, and it went nowhere. I found that the younger you were, the less likely you’d see why someone might want it. Curious, that.
There are some privacy issues to putting ICE information out beyond the pin-lock, obviously, because f someone gets ahold of your device they can access it and find out some things about you. On the other hand, in a medical emergency having that info might mean the difference between getting timely treatment — or not. Or the difference between having your family contacted if you run into trouble — or not. And that ICE info might make it easier for a well-intentioned person to return a lost phone that they found. Every person would have to decide which info to make available, and as long as the ICE program itself is a voluntary choice, why shouldn’t it exist?
It seems like a simple thing to make happen. Hopefully you’d never need to have it used. But if you end up in a situation where an emergency responder is trying to figure out who you are, it seems to me you don’t want your PIN standing in the way. I wonder how many IOS users don’t turn on their pinlock because they don’t want their contact info locked up in case of an emergency?
If Apple wants to offer 4G in MacBooks, they can start whenever they want. Doing it properly will just take a bit more effort than adding a modem.
I think it’s a bit more complicated than people think.
Look at what Apple had to do with iPhone 5 to support LTE globally, vs. 3G. Lots more models of the phone because of the fragmentation of the LTE network frequencies.
Translate that to the computer line, where even with Build to Order, Apple’s kept the number of models and the variations down to a minimum, and the trend has been towards fewer choices in recent models, not more.
So to support 4D in the laptops, each laptop model is going to have to be set up to support 4G in all of it’s international variants. That complicates inventory and build management, distribution and etc. Don’t forget licensing and regulatory testing and approval — and the propensity for new models to leak via that process.
And don’t forget that 4G is only recently built out well enough to support widespread adoption in the US, and it’s adoption elsewhere is still rather — spotty. It’s one thing for Sprint to come out with a 4G model that sells 200 units in the US so the bleeding edge geeks can buy it (and mostly run it on 3G networks because they don’t have 4G yet) and giggle about how Apple’s so behind the times. It’s another to sell out a hundred million 4G iPhone 5′s in 40 countries.
The combination of 3G speeds and build complexity/logistics made putting cellular into laptops fall in the “not worth it now” category. LTE changes that equation, but LTE’s only been in Apple’s product line a few months, and I expect Apple would want to prove out the networks and technology on the mobile devices before rolling it to the computers.
But I wouldn’t be at all surprised to see cellular support hit OS X at the next WWDC and roll out to the computers next fall, or this time next year. I would be surprised to see it happen sooner. And I’m not at all surprised it hasn’t happened by now, given the realities of how Apple builds laptops and what I see as consumer demand for this (which is: prior to LTE, very weak).
But I’ll tell you, having recently upgraded from a first-gen iPad/WIFI to a Retina iPad/LTE, I’m sold. But I’m curious how they’re going to solve the issue of LAN vs WAN when it comes to things like devices in the home. Running both WIFI and Cellular in parallel? That’s very different than the IOS model…
Was having an interesting conversation this morning with Om and Hunter about the recent firing of Richard Williamson from Apple over the Maps debacle. Hunter posed a question that, in hindsight, seems like such an obvious one to ask:
How does that make rest of co feel? Enforces ‘only ship quality’ or makes people risk averse?
It depends greatly on why he was fired. We don’t know for sure, since we aren’t there, but was he fired because the maps software was seriously flawed?
Or was he fired because he lied to his bosses about the quality of the maps software, or misled them about the status?
I’m willing to bet, from my time working at Mama Fruit and dealing with Eddy and his teams, that the latter has a big part to do with this firing.
If you think about the reality of shipping something like IOS and the Maps software, it’s tightly integrated with the entire OS, so it’s not the sort of thing you can simply decide to not ship and stick the Google Maps back in. This isn’t the podcasts app, it’s a key, low-level part of the operating system. So if you think of this beast from a view of project management, the “go/no-go” on including maps was a year or so ago (or further), and after that, the train has left the station. If you don’t ship the maps stuff, it means you don’t ship IOS6. And if you don’t ship IOS6, it means you aren’t shipping iPhone 5. (the whole “why they had no choice but to ship Maps as they were” would be its own blog post…)
And that’s really bad.
So you’re shipping. After that, it becomes a question of how you manage the situation. Do you keep everyone aware of the problems and work with all of the involved teams (marketing, etc) to set the right expectations? Or do you tell everyone it’s going to be great, craft a demo that avoids the problems and makes it all look perfect, and hope to god you get the bugs wrangled before anyone finds them?
One of the mis-steps of the IOS6 announcement to me in light of how Maps turned out in reality was the disconnect between how Apple sold it to us, and how it really worked day 1. That mistake was completely avoidable. Apple could have positioned the Maps software in a very different but positive way, acknlowedged the flaws and that they needed the users to help them identify and fix things — turn this into almost a game, give away store coupons for being the first to find problems. And said up front that there were going to be hiccups, but that in the long-term, this switch made the birthing pains worth it and everyone would benefit in time.
The situation could have been completely defused. Instead, they way oversold Maps as awesome, and set themselves up for the face plant.
Why? I kept going back to my view that if Apple management knew they were going to have to ship a buggy maps app, they wouldn’t have bugled how wonderful it was. But what if the real problems were hidden from them? What if the maps team hid the real problems? Crafted great demos and told everyone things were fine?
Then the rest of the teams wouldn’t know they were stepping on a landmine until it went off.
And if you’re responsible for managing that fiasco up to your management and to the other teams relying on you?
Well, you deserve your walking papers.
Not saying that’s what happened here, but — it sure seems like a reasonable scenario based on my time there. And it sure seems a lot more rational than Apple knowing the Maps stuff was going to suck Day 1 and still selling the hell out of it at the announcement. I keep thinking that if Tim Cook knew the tool was going to be iffy on initial ship, he would have handled the announcement differently.
So perhaps he didn’t know. And perhaps now, some heads are going on up pikes. Not for the software being bad, but for hiding it from the bosses…
And to tie that back to the original question, if he was fired for misleading the company about the quality of Maps, then frankly, most of Apple is probably cheering this (probably quietly). That’d be a good thing and a strong message to be sent through the company.
Sometimes, software doesn’t come together as fast or as well as you hope (I know, most of you are going “duh!” right now). That’s something that we all understand, and we can deal with in some way or another. Like, oh, not making it the focal point of the announcement keynote.
But lying about it or hiding the problems so those you work with get sideswiped?
If there’s one thing bosses and co-workers hate, it’s unpleasant surprises.
I got into a twitter discussion yesterday with some people about turning off Feedburner on their blogs, since the rumors are Feedburner is going away (and even if it’s not, it’s been unreliable and is clearly not a priority for Google). I made a decision to turn off Feedburner over a year ago because I felt Google was going to do away with it at some point, and since then, I’ve seen nothing to indicate Google has plans to enhance the tool. It seems to be leaving it to slowly die of neglect. Because of that, I’m glad I stopped using the service, and I suggest everyone consider removing their RSS feeds from it while they can plan the migration rather than waking up one morning to unpleasant surprises and a crisis migration.
As part of that talk, I did some quick research on what needed to be done and I thought it might be helpful to others to put those notes online here. These notes are assuming your site is running with WordPress, but they should be generally useful for most sites on other platforms like Drupal.
There are three aspects of Feedburner that might impact someone trying to migrate themselves off of the service:
- RSS Feed
- Email subscriptions
Most users use Feedburner to redistribute their RSS feeds off their site. In return, they get some stats on usage, and Google spends some of it’s network feeding the RSS instead of it coming off of your site. Migrating from feedburner on your WordPress site involves changing your RSS links to point to your local feed instead of Feedburner, and then disabling Feedburner and having it point existing RSS subscribers back to your site.
The RSS feeds in your wordpress can be set up either by the use of a plug-in. The first step in migrating your RSS back to your local feed is to disable whichever plug-in you are using. (note: if you read this instruction and go “huh?” then you probably need to find a friendly geek to help you through this).
It’s possible that your Feedburner feeds were hard-coded onto your page, so you need to examine all of the links to see whether disabling the plug-in converted them back to your local RSS (the local RSS feed is typically a URL like <site>/feed). If you still see links pointing to Feedburner, you’ll need to dig into your theme files and find and change the hardcoded links.
Once you’ve taken these steps, all of your RSS links should point to your site instead of feedburner, and all new subscribers will subscribe to your local feed. Your existing subscribers are still subscribed to you via Feedburner.
To change that, you need to log onto Feedburner. There is an option to disable the feed. Feedburner will try to talk you out of it (of course), but if you insist, it will disable it, and for the next 30 days when someone goes to the old Feedburner link they’ll get a redirect pointing them back to your RSS feed. Most RSS readers are set up so that when it sees that redirect it’ll automatically update the subscription to use the new link directly.
So, once you’ve updated your site to stop pointing to Feedburner, and disabled the feed on the Feedburner site, you’re done. For the next month, when your existing subscribers pick up the feed, they’ll be automatically redirected to your local feed. It’s always a good idea to blog about the change for those users who’s RSS readers don’t follow the redirect properly, but it should be automatic for the most part.
Feedburner has an option to let users subscribe to your site via Email. If you use that, migrating the email off of Feedburner is going to complicate this, and you should do that before trying to migrate the RSS.
The bad news: you’re going to have to choose a new service to handle your email, it’ s not something you can (or should) handle on your WordPress site directly. trust me on this, I used to do email for a living. The good news: there are a number of sites that do this kind of email (but depending on the size of your subscriber list, it might cost you). Here are links to pages that explain this migration for a few services:
I’ve worked with aWeber and MailChimp in the past for various projects and both of them I’ve found are reliable and work well with good support. I haven’t worked with Feedblitz. you’ll need to evaluate these options and decide which one makes sense for you and what the costs are. All of these sites should be able to handle a migration from Feedburner.
This migration may take some time, especially getting your site updated. I’d suggest setting up and testing the new email setup and then updating your subscription pages, and then doing the Feedburner migration in three separate steps to minimize the possibility of chaos. One nice thing about migrating to a commercial emailer is that if you decide to do a site newsletter as well as a blog posting remaining setup you can integrate the two and do some marketing to get people on the e-newsletter.
The big loss in moving away from Feedburner is the loss of some easy statistics on how many subscribers you have. There aren’t any great options for replacing this, but there are a few things that might help. If you use Google Analytics (you do, right?), then check out this solution form ZoomMetrix. It looks like a nice solution, but the negative is that it’ll only work for new subscribers. There’s no easy way to add this tracking to existing subscribers.
The other way to get subscriber stats is to parse out your web site log files. There’s a project underway to build a script to create good stats out of an Apache log file; this is something I’m looking to implement for my site. Or you can do what I do, and mostly just not worry about it much. Seriously.
Hopefully, these links will help people looking to migrate off of Feedburner. If you have other suggestions, improvements, or corrections, please drop me an email or leave a comment.
An interesting idea: App.net will be paying “at least $20,000 per month” cumulatively to app developers, divided according to each app’s popularity and user satisfaction ratings. So a reasonably popular app might get a few thousand bucks a month.
It’s a strange move, though. It doesn’t look confident. This reminds me a bit of RIM’s strange $10,000-guarantee-if-you-make-at-least-$1,000 deal. (Apple and Google never needed to pay developers to make apps for iOS or Android.)
You’re trying to solve a chicken and egg problem here.
Consumers are less likely to buy into a platform if “the apps they want” (see note 1) aren’t available for it.
Developers are hesitant to commit to developing for a platform where the revenue opportunities aren’t there.
The challenge is to bridge that gap for developers. You can
- ignore it and pray
- give them non-financial incentives, such as marketing and promotion, high profile in product launches, and other partnership goodies
- pay developers to put apps on your platform (effectively, going to, say, Starbucks and offering to fund the app development for them)
- subsidize the app ecosystem to get it off the ground and give developers a revenue stream until it grows enough to be sustainable on its own
For the first two, your platform needs to be pretty persuasive today if you want to go up against IOS and Android and expect developers to just wander in and play in your territory. When we were booting up webOS, it was (relatively) easy to do the “not Apple”, because Android hadn’t yet booted either, and all of the other platforms were missing or tightly managed. Today, booting a platform like webOS would be a lot harder, IMHO.
So you need to inject money into the app ecosystem to help developers survive as it boots. Typically the worst thing you can do is pay developers to build apps; they’ll take the money, see how little of it they can spend to get an app out the door, and you get a crappy app and they don’t care because they’ve been paid. They invested in shipping the app, not investing in the ecosystem, and in lots of cases, will never care if it sells a copy.
So it’s all about finding ways to build revenue into the ecosystem in ways that give incentive to both publish apps and to have those apps quality ones and well received by the users. with webOS, we did a series of promotions (please, god, don’t call them contests (see note 2)). With webOS, we tried to structure things to reward success with end users — most downloaded apps, for instance. With the Touchpad, we injected money into the ecosystem by attaching a $50 credit to every TouchPad sold, allowing buyers of the tablet to choose how to spend it. Both of them.
FWIW, I’m not sure $20K a month will do a lot to boot the ecosystem. That doesn’t spread very far when you’re talking about trying to help developers pay back development expenses. For webOS, our budgets were more like a million a quarter, just for comparison.
So both RIM and app.net are on the right track, if these are implemented properly. RIM’s guarantee makes sense because they’re trying to attract the class of developer/company that already has an IOS and an Android app and is saying “what’s in it for me? why should I bother?” — at least now, there’s some financial incentive, where, honestly, marketing/promotion or “hey, we’re not going to suck in year, you want to be part of this!” aren’t going to generate much enthusiasm. You put the $1000 floor on earnings to avoid getting flooded by five thousand tip calculator apps that exist only because people want a chunk of the money you’re giving away. It saves you from paying out money to the, um, lower-caliber developers that are simply trying to grab your payout and not really trying to build a usable app that’ll help your platform.
IOS doesn’t have to do this because they are the 800 pound gorilla, and have a zillion units in the hands of consumers looking for apps to buy. Ditto Android. What RIM is trying to do is get into that game again. It’ll be interesting to see whether they succeed. And they can’t do it by making promises or asking people to invest in building apps in hope of future returns. The class of app they need to attract will nod politely and then go plan their IOS next generation app instead.
App.net is in a different place; I think this is more about encouraging some of the twitter developers to give them a shot, and to create an ecosystem where the developers have a bit of help so that they can give the apps the time for the platform to find a large enough audience. The developers that app.net are likely trying to attract are a lot different than the ones RIM need to grab (app.net is going to be the individual/homebrewer and the tiny shop, RIM needs corporate and mid-sized shops to buy in), but I still wonder if that amount will make a significant difference. We’ll see…
(note 1: “the apps they want” is actually fairly hard to define. There are likely 20-30 apps that are universal to almost everyone, from email and contacts and calendar and maps. There are a larger set of a few hundred that large chunks of potential buyers are going to want SOME of, whether it’s a Starbucks app or Netflix or their bank’s banking app or whatever. And most people have a couple of apps in the “gotta have” pile that are definitely niche apps, but the lack of them can be a killer. In my personal case, those “gotta have” niche apps are my birding and nature guides. A platform I can’t get those on I probably won’t consider, but 95 out of 100 readers of this blog post will shrug and go ‘huh?’? Everyone has those apps — and none of them are common apps in any way, shape or form, which is why you need to try to build a diverse and large app ecosystem. It’s basically the same reason why a steakhouse has a token chicken or fish dish on the menu: to prevent that one “I won’t eat beef” person from keeping the entire dinner party from coming to that restaurant…)
(note 2: the nanosecond someone utters the word ‘contest’ dozens of lawyers warp in through a wormhole and start having hissy fits. it turns out that having a contest is an incredibly complicated and regulated process and involves things like creating ways for people to enter without actually spending money or owning your product and things like that. So you end up sitting down with your lawyers and making damn sure you use language that doesn’t turn it into a contest. Even if it kinda looks and smells and quacks like one.)
There’s a new iPhone in town, and with it, a new release of IOS. The new iPhone is selling a zillion units and making Apple a few zillion dollars. Meanwhile, in some alternate universe, Dan Lyon is trashing everything in the hope that someone, somewhere, will link to him and maybe some folks will read his babblings again. Sorry, Dan, not me.
But with every release, it seems, the media and pundits have to find something to turn into a Major Crisis, and for IOS 6, that crisis is the new Maps. Apple’s removed the old Google Maps and replaced it with their own. Horrors, it’s got issues. Horrors, it’s not perfect. Obviously, this is the death of Apple. (But before you declare that, go read Kontra).
The fact is, the only thing more trendy than finding excuses to complain about Apple is buying their products. Which drives the complainers crazy, it seems. So every time Apple releases new products people find reason to complain and declare doom, and every release those declarations of doom are roundly ignored and the product goes on to be a massive success. Fact is, not having a controversy to generate page views over is bad for business for many of these blogs and media sites, so of course they’re going to find a controversy. “Hey, damn, this is great” doesn’t trigger outraged comments and doesn’t drive eyeballs or ad rates or readership. And frankly, there are segments of the geek/tech pundit crew that seem to have hit that point where if we gave them unicorns, they’d complain about them being purple instead of blue. And if we gave them unicorns two years in a row, they’d complain, because unicorns are boring and the industry is really demanding dragons now.
Honestly, it’s pretty sad to watch. But I don’t expect it to change any time soon.
The fact is, the maps we get with IOS 6 are mostly okay and definitely have some bugs in the system. It’s not as good as Google’s maps, especially away from North America. And the vast majority of users won’t ever notice, because their usage of maps is very casual. I’m sure Apple’s also going to be working hard in the background to clean up the issues and fix the problems that get reported to them. In six months, this whole thing will be largely forgotten, except for a couple of tumblr blogs nobody will visit until the next iPhone release when the pundits do their “remember when?” articles…
This all sound familiar? It should. It sounds a lot like Antennagate (iPhone 4). And the MobileMe Launch, which was never a great product, but pretty quickly became a decent and boring one. Remember when Apple revamped iMovie? or Final Cut?
Fact is, Apple isn’t afraid to take apart a product and push it in another direction if they feel it’s the right thing to do over the long term. Today, Antennagate has been proven to be a lot of smoke over very little fire. MobileMe moved forward and became iCloud, which is a huge part of MacOSX and IOS now, and is mostly ignored by the tech press because, well, it’s decent and boring. iMovie is back to being a pretty good consumer product, and Final Cut is actually pretty well liked in the advanced consumer and prosumer segments, which is where Apple wants the product to live. (pretty much everyone I saw that had a cow over the new Final Cut replaced it with a 5 figure Avid system — i.e., people who spend lots of money on their setups. And they had some legitimate issues over being abandoned by Apple, but Apple also has a right to choose that it doesn’t want to support a market segment any more, too)
Maps are headed down that path, too. Apple bought it’s first mapping technology company (Placebase) back in 2009. In fact, do a google search on Apple and Placebase, and you can see all of the articles written at that time about how Apple was replacing Google Maps. Here we are, three years (and at least three mapping technology buys) later, and they actually did it.
There’s been some amount of “we don’t know who pushed who into removing Google Maps” speculation going on. Honestly, given Apple’s been working on this at least four years, it’s hard to think Google pulled the trigger on this. More likely? The last time Apple and Google renewed the agreement on the maps, Apple came away from that thinking that they needed an alternative to Google before the agreement needed to be renewed again. Did Apple see Google boost the cost of the technologies and have no choice? Perhaps. Whatever, I think it’s pretty safe to say that Apple’s been planning this for a while.
The big question that’s been asked is “how could Apple ship something this buggy?” To which my answer is: “Have you ever tried to debug a data set like this?” I’ve seen a lot of writers complaining about the quality of the data. I’ve only seen two offer substantive suggestions on what Apple needs to do to fix it (and both are mapping industry insiders). I haven’t seen anyone offer any real suggestion on what Apple could have done, other than vague “it needed more testing”.
Data sets like this frankly defy testing. The only reason Google Maps is as good as it is today is it has a multi-year head start at fixing reported bugs. Ultimately, the only way you clean up a data set like this is to shove it out into the real world and take your lumps while you and your users beat it into shape.
Let me offer a similar problem I’m intimately familiar with. Someone dumps a list of 50 million email addresses on your desk (or in your Dropbox). Your job is to debug and clean up that data. How do you do that?
It is possible to find and fix/delete syntactically broken email addresses (although honestly, there are a bunch of RFC822-legal email addresses in the edge cases that I promise you will fail or destroy pretty much every production email system out there, which is okay, because nobody uses them. So do you clean up this list to be correct to the standard? Or do you define a subset of the standard and clean up to that? – even answering the question “what is a legal and valid email address?” is subjectively complex)
You can come up with lists of domains or account names you know you want to exclude from the list. Domains like “whitehouse.gov” probably shouldn’t be on there. Role accounts like “abuse@” or “root@” shouldn’t, either. You can also come up with specific email addresses you know you should exclude, like “email@example.com” or “firstname.lastname@example.org”. You can snuff out email addresses for which there’s no valid DNS and/or MX records and are therefore not routable (but there are complexities to that, too. In reality, you probably want to mark them and try at least three times over a two week period to get away from transient issues…)
In the end, what do you have? A list of email addresses that is somewhat smaller than the original list, one that you’ve been able to remove the typos and syntax errors and some percentage of the abuse/attack and other problem accounts. You have a list that you can pretty much guarantee is conformat.
But that’s about it. Do you know if it’s a good list? A bad list? Are those email addresses valid? they’re syntactically correct, but do those addresses exist and are there people reading email sent to them?
You still have no idea. And you won’t, until you actually start sending email out to the list.
Welcome to Apple’s Maps problem, except this list of 50 million email addresses is a LOT simpler and a much smaller data set than the mapping data.
Do more testing? Anyone have an idea how much testing Apple did? (I don’t). But I know if I have a list of 50 million emails, you could hire me a hundred temps for a month to roll through the data and it wouldn’t significantly change the quality of the list. We could identify more problem emails and remove them, but honestly, that’s a lot of work when sending emails and trapping the bounces would do the same for a lot less time and money.
The mapping problem is the same problem (only a lot bigger and harrier). Would hiring a thousand temps for six months solve the problems we see in this release of IOS?
It’s solve some of them. If a tester happened to look at the imagery of the Tacoma Narrows bridge, it’d be obvious there was a problem that needed to be fixed. But what percentage of the maps are we going to cover, and how are we going to cover it? do you think that even with a huge set of testers looking at random data sets out of the mapping data that particular problem would show up in the testing? Could you build a team that could cover, say, 10% of the mapping data in any time worth doing? And at what cost?
But think about some of the other problems we’ve heard about, such as an airport being turned into a farm. Would a random tester viewing that random map page have a chance of finding that problem? It looks just fine: it’s syntactically correct, just like those emails. It’s just wrong.
So if you want to debug something like map data, the only way to do tehat would be to build a testing team that has members with local knowledge of widely distributed locations and have them debug the areas of their expertise. In other words, you’d need to hire a global team and coordinate their testing globally as each group tests their local part of the data. How granular should these global teams be? Would a team based in Cupertino recognize a missing airport outside of Cody Wyoming?
Hopefully you start to see the scale of the challenge. At some point with that list of 50 million emails, you have to say “okay, let’s use it and see what happens” — and then capture the feedback (bounces, complaints, etc) and fix it as you go along.
Same with the maps. At some point “do more testing” doesn’t actually improve the quality of the data, it just costs you time and money.
That’s the point Apple is at now. Where the maps go from here depends on how well Apple is set up to receive, evaluate and repair complaints from users.
This is a new class of problem. The Maps looks like an app, smells like an app, and it walks like an app, but in reality, the vast majority of the guts of it is a huge database that’s living in a server, so you can’t treat it or test it like an app, and the old school testing techniques for an app fail miserably. These “big data” solutions are still an emerging part of the industry, and how to deal with, test and evaluate the data is still something everyone is grappling with — just ask any Hadoop geek.
But I think a basic fact is that in a lot of cases, the only way to validate and fix the quality of these data sets is to push them out the door and see what happens when everyone starts poking and prodding at them, because not only can’t you hire, train and manage a testing team large enough to deal with data sets this large in a rational way, doing the testing almost requires an infinitely large set of testers, each with intimate knowledge of some small subset of the data.
Which, if you think about it, only exists in one place: your user base.
So you can gripe all you want at Apple for the quality of the maps they released. I’m sure they knew about it. Just like we could know that list of 50 million email addresses was “clean”, until you actually start pushing it out the door and having it interact with the real world, you have no clue out “good” it is.
So if you’re one of those people complaining about the quality of the maps — stop and ask yourself how you would have done the testing better to avoid it. Not just for that little part you know, but on a global basis at a local level. Because that’s what testing that data set needs.
Good luck. you’ll need it.
I am convinced that Apple will release a retina iMac in late 2013, and chances are, it will be a “Pro” model to replace the Mac Pro.
Some interesting speculation on where the Apple product lines might head and what retina displays mean for them.
I keep thinking that there are a number of pieces of Apple’s product line due or overdue for the classic Jonathan Ive “I think we need to rethink how we do this” treatment: the iMac hasn’t had a significant redesign in a good while. Ditto the Mini. Ditto (except for the move to Thunderbolt) the Cinema display.
The realities of the market Apple is selling this stuff into has changed significantly, too. More and more of us have moved to a “laptop first, laptop only” relationship with our computers. The market for the Mac Pro continues to thin out and it’s become a true niche device for serious high end graphic/video/photo geeks and developers who need it’s power to drive Xcode.
The mini has split it’s audience into people who need/want a desktop to supplement their laptop and people who use it to drive their home media systems. It’s also used by some (as are iMacs) instead of Mac Pros, because in reality, the Mini and iMac more than serves the needs that used to require a Mac Pro for many users.
Apple has unofficially said the’ll have a replacement for the Mac Pro out in 2013. It’s fairly safe to assume there’ll be a major move into retina displays, and so we ought to see the iMac revamped, and the Displays, and….
I keep wondering if it really makes sense for Apple to manage all of these products? Especially if you start thinking that it’s likely they’ll do both a Retina iMac and a non-Retina iMac to keep the pricing of low-end units accessible, it seems to me the product line starts to get — complicated.
If I tried to think this through the way I’d expect Apple to, I start thinking it’s time to blow it all up and do it differently.
You start with the Cinema Display. Apple currently does three: the 27″ display, the 27″ display with attached computer (aka iMac), and a 21″ display with attached computer.
So how about 24″ Display, 24″ retina display and 27″ Retina display?
And then if you want, attach a computer to it? Instead of doing an iMac, a Mini and a Mac Pro, you do a CPU unit that can either attach onto a display and act as a consolidated computer, or run headless. And you do a consumer class version and a “mac pro” high end version. One form factor, multiple price/performance points.
To support the data needs that some use the Mac Pro for, you also build a Data unit. It connects to the CPU unit via thunderbolt, and you can mix and match up to, say, six or eight drives into it. It’ll support various raid configurations, and we can all is “mini iSan” or something.
With USB 3.0, bluetooth, Thunderbolt and Apple’s modular power setup and magic ability to create connectors, they could create a set of pieces that give them a lot of flexibility to sell standard configurations that hit many different price and performance points. Standard configurations can ship with pieces already mated together.
And it’d give both Apple and its customers the ability to upgrade a given piece of the system when they want, where with the iMac today, if you want a faster CPU, you have to buy a new monitor with it.
So if I were running the show (hah!), I’d do the next generation of hardware differently. Think modular. Think flexible. And by doing so, you’re actually making your life managing the product life of all of the product lines much simpler….
As ReadWriteWeb’s Brian Proffitt explained last week, omitting NFC is a conscious decision that can be easily reversed in the future. But unlike earlier missing iOS features like copy-and-paste, multitasking, and yes, an SDK, NFC is far from a no-brainer addition to Apple’s flagship product. Critics are stuck in the usual mud of tracking technology rather than utility.
It’s no coincidence that the “Tech Specs” link atop apple.com/iphone is dead last. Apple’s best marketing has always been about what a product does, not what it has. Forget MHz and GB and mAh — how much faster does it launch apps? Play games? Snap pictures? Load web pages? How many hours of video and talk time? These are things that anyone can not only understand, but appreciate.
Behold the NFC issue. What can people do with it today? All we hear is what they should be able to do with it someday. Search the web for “near field communication” — the 2010 articles read exactly like the 2012 articles. And boy are they wordy.
“What can you do with it today?”
That’s the rub. NFC is one of those technologies that requires a lot of moving parts. It’s not just something you stick in a phone, it’s something that requires support by credit card processors to support transactions and retailers who need to update their processing terminals. Just sticking it in a phone is a recipe for disaster, and Apple doesn’t do disaster’s it can avoid.
And while NFC would be something Apple would build support into IOS for, I think it’s a technology crying for a developer API, and so it’s very unlikely Apple’s going to surprise the universe shipping it in a phone without advance warning to the developers. Imagine the joy among the developer community if iPhone 5 shipped with NFC, IOS 6 has a surprise API supporting it, and the only apps ready to use it were Apple’s and a half dozen key “special” partner companies?
No, when Apple does NFC (and I think it’s likely they will), NFC ought to be a WWDC announcement, with Apple coming out on stage and with their partners out doing the infrastructure showing up and everyone showing just how great NFC is going to be, once it ships in IO7 (or 8) on the iPhone 5S, and, of course, “here’s why you need to get going on your NFC support in your apps today!” as part of the show.
That give the partners (Visa, amex, Discover, etc) 6-9 months to build out the terminal infrastructure and developers a chunk of time to build the apps, and everyone some time to make sure everything works together and is ready to go. You’re not going to build an NFC infrastructure out into the retail market in secret, the universe is going to see it coming. So I can’t see Apple trying. Instead, it’s going to take the card processors to take a lead to build out the retail side of this, and then you’ll likely see both Apple and Android build it into their phones and OSes. One platform or the other might get a head start here as a preferred partner, maybe.
But NFC isn’t the kind of technology that you can stick in a phone, do the “look under your chair, everyone gets a car!” surprise with it, and expect it to succeed. It can’t stand alone, and the infrastructure won’t magically appear. And as of today, it doesn’t exist here in the U.S.
So NFC is this year’s “we want LTE” — the rallying cry of the geeks who expect a technology to ship years before the infrastructure needed to make it usable in any real way is actually available to support those who want to use it…
But Matthew McNulty, the former senior director of the HP Enyo team, Enyo being the successor to webOS, said he would be surprised if HP used webOS for its new smartphone since many engineers have left the company, including McNulty who departed HP for Google in May.
However, if he still worked at HP, McNulty said the announcement from Whitman would have been devastating.
Matt’s right, and I think he speaks fairly for most webOS/Palm people, current and former.
But I think we need to be careful about trashing Meg here.
We have to remember that Palm (the company) was a bit of a cluster — and the first phone shipped when it had to, not when it was ready to ship. And Palm was running out of money. And then HP stepped in and turned Palm into a much better funded cluster, and HP really did try to help Palm be successful. Except HP then got sidetracked into its own series of clusters, whether it was Mark Hurd (who along with Shane Robison were the primary supporters behind buying and funding Palm) being forced out over his choice of dinner companions, or HP hiring Leo (WHAT WERE THEY THINKING? OMG, WHO THOUGHT THAT WAS A GOOD IDEA?) and Leo trying to blow up any part of HP he didn’t understand, which was big parts of the company.
So when Meg was brought in, her primary function was as a field surgeon, trying to keep the patient alive long enough to get to the hospital. Massive damage was done to HP and to webOS, and most of the webOS damage was almost of the “innocent bystander at a drive by shooting” type as a side effect of Leo’s attack on the PC division.
Meg could have just written webOS off and shut it all down as a damaged investment not worth fixing. Given how many much bigger and strategic problems she had at HP when they brought her in, nobody would have blinked at that. But she brought in Marc Andreesen to help her figure out what to do, and they committed even more funding to give it a third life as an open source technology. Whatever you think about Leo, HP and how badly they screwed up things with webOS and Palm, it needs to be remembered that at least a couple of toes were shot off by Palm itself with it’s own gun before Leo pulled out the Uzi.
And in all honesty, Meg has done a rather amazing job of giving WebOS another chance, and has been honest about it. She could have used the “there are just too many bigger problems I need to deal with” excuse and shut it down cold. She could have put it on life support, or funded it just enough to let it fail and then said “I tried”. She could have just stuck it in a closet and quietly killed it a few months later when things quieted down. But she put an honest effort and honest levels of funding into giving it a shot, and she deserves full credit for that.
And to the credit of the folks sticking it out with webOS (unlike myself, who ran like a rat off the ship when I had a chance to without any regrets…) they seem to be doing what they need to do, and I’ve been really impressed with the results so far. So maybe, just maybe, what Meg set in place will succeed. I’m sure rooting for it. And she deserves credit for that. Given how badly Leo screwed everything up, I’m frankly amazed how much progress she’s made at HP so far. Still a long, hard path for the company as a whole before it’s fixed, if it ever is, but IMHO, it’s in good hands.
So here’s an interesting exercise: Imagine if Amazon had acquired Palm and WebOS instead of HP. While WebOS and HP’s TouchPad tablet were ultimately failures — and the deal timing doesn’t really work — it may have resulted in a more interesting partnership and more successful products.
What WebOS did well is exactly what Amazon’s Kindle Fire needs: A beautiful, clever interface, second only to Apple’s. (And even better than iOS in some ways.) Combined with Amazon’s expertise in e-commerce, digital media, and its aggressive pricing, a Kindle TouchPad might be an even more compelling device than what Amazon has built on its own.
There are some major problems with this idea, of course. Amazon’s app ecosystem mostly exists because companies are already developing for Android. Building the Kindle Fire around WebOS would have meant far fewer apps, at least in the short-term. Or perhaps the WebOS team could have remade its user interface for an Android-based tablet, but who knows how long that would have taken or if it would have been any good. (Not to mention any economic or logistical problems with this combination.)
But, still, an interesting idea! Jeff Bezos clearly cares about becoming a great tablet maker, and Palm’s team — led by ex-Apple executive (and now Amazon board member!) Jon Rubinstein — might have helped. It’s hard to imagine Amazon blowing the Palm acquisition worse than HP did. It might have even been a great combination.
The app ecosystem isn’t that big a deal. you could take it a couple of ways. If Amazon has bought Palm, they would have had Palm’s partnering and business development team, which was pretty darn awesome. You want to convince people to write apps for a platform? First, you need a team who knows how to make those connections and sell the opportunity. And then you need an opportunity they can sell. “Hey, this device will be plastered on the front page of Amazon.com for the next two years at this price point, and we’re going to push it hard into the hands of everyone we can get it in front of. And if you commit to shipping this, we’ll make sure your app gets a month of favored placement in the catalog during the holiday season and you can demo it at the launch announcement”. If you need to, for key apps you can sweeten the deal with anything from outright subsidies (“we’ll hire two developers for three months”), marketing and publicity, any number of things.
Amazon’s story was easier being on Android to some degree, but this is a very manageable situation if you have the right people and management commitment.
Or Amazon could have built an Android compatibility layer into a WebOS-based device. Quite technically possible for the right teams.
Or what I’d most likely have done in their shoes: take the webOS user-visible interface components and port them to Android to replace the Android versions. Basically throw out the underlying technology and run the webSO front end on Android. The bad news (for Palm/webOS at least) would be that Amazon wouldn’t have needed a huge chunk of Palm to do that, it only would have needed to bring over a 100-150 people, more or less. Which is, from what I can see, about the size of the webOS GBU under HP today, so the end result would have been about the same, at least as far as leaving dead bodies on the side of the road during the death march…
And if Amazon DID investigate buying Palm back at that time (and I honestly have no idea one way or another), that’d be the thing that killed that deal. Palm at that time was only interested in a buyer that would keep them together and let them continue to try to build the product. “Parting out” the company was only an option if they couldn’t find a buyer that’d continue the operation. HP would and did. A deal where someone bought Palm and then laid off 2/3 of the company wouldn’t have been on Ruby’s A or B lists (and there were — rumors say — a number of players looking to buy Palm for the patents and throw all of webOS and it’s people into the recycling bin…. Depending on what rumors you heard, ALL of the offers other than HP were that kind of deal. I know that’s what I was expecting…)
There are rumors (and again, I DO NOT KNOW. I wasn’t in the meetings, if there were any) that Amazon investigated buying webOS after Leo blew it up and HP was looking at options (and exits). And that Amazon ended up walking away from it because the costs of operating the organization was way beyond what they considered affordable because of the costs associated to supporting the cloud aspects of webOS. So it’s possible Amazon kicked the tires on this twice, but if they did, the first time, it probably was a deal Palm wasn’t interested in, and the second time, the price tag made webOS too expensive for them to take on.
So I think webOS on Android on Fire (so to speak) was definitely something that could have been considered and could have given Amazon some nice options to work with, but the cost of making ti happen would have been way beyond what it would have made sense to pay to get it.
No huge essay on the outcome of the Apple/Samsung trial, but a few bullet points I thought I’d write down for your amusement…
- Apple spent 5 years and a lot of resources inventing the original iPhone. It’s hard to think back to what life was in mobile phones at the time, but it was, more or less, a device like a Samsung Blackjack. Which was a decent and boring phone.
- Samsung spent literally weeks grabbing pieces of Apple’s design and technology and stuffing it into their phones. The people attacking Apple and saying this decision stifles innovation don’t understand what ‘innovation’ means.
- For the record, I think the current patent system is broken. But until everyone comes up with a consensus of how to fix it and get that consensus implemented, those are the rules.
- There’s a segment of the geek population that has a strong opinion of “if we don’t like the rules, we’ll complain and ignore them”. If you think the rules are broken, fight to get them changed and fixed. Don’t just whine. Many companies, from Napster to now Samsung, have ignored the rules and ended up paying for it the hard way.
- My views of the patent system being broken, I believe Apple deserves some protection from what Samsung did. If you make it legal and acceptable for a company to grab innovative ideas that quickly and that easily, where is the incentive to keep innovating?
- Which parts of what Apple did deserve protection and for how long, I don’t pretend to know where the lines get drawn. I do hope this decision catalyzes that discussion and pushes patent reform forward. (I’m not holding my breath. I also believe we need trademark and copyright reform. I’m not holding my breath there, either — but the continuing of extension of copyright and loss of material falling into the public domain is another aspect of this same big problem).
- Samsung’s best attack on appeal is through prior art, which I think the jury mostly ignored. And I do believe on appeal some (but not all) of this judgement will be set back. And should.
My bottom line: Apple deserved to win this case, but I’d like to see the win ultimately narrowed and tied to some key intellectual property innovations. Samsung deserved to lose, and their lawyers need to have a long, loud talk with company executives loosely titled “what the hell were you thinking saying those things in writing, anyway?” They were so blantant at how they ripped off Apple that it’s hard to have any sympathy for them, even given my belief the current patent system is pretty damn broken.
It is somewhat disturbing at times when the bandwagon takes of and speeds up, without people being critical. People stand up for situations that may never have happened, and spin on it which ultimately results in that it will be trated as facts, or a faktoid.
We wanted to test this, how easy is it to spread disinformation?
Apple is the world’s largest company, so they can take a few knocks. The community around Apple is often very active, especially before an upcoming Keynote where it is expected that the company will introduce new products. In September is one, and everyone expects the iPhone 5 to be announced. Rumors are flowing about the phone, its appearance, its features, its materials and so on. We found this was a fitting goal for our test.
One afternoon we sketched out a screw in our 3D program, a very strange screw where the head was neither a star, tracks, pentalobe or whatever, but a unique form, also very impractical. We rendered the image, put it in an email, sent it to ourselves, took a picture of the screen with the mail and anonymously uploaded the image to the forum Reddit with the text ”A friend took a photo a while ago at that fruit company, they are obviously even creating their own screws ”.
Then we waited …
Nice hack. I admit I looked at the screw, decided it was probably a plant, and sat back to watch the show. I wasn’t disappointed. (why did I think it was a plant? The screwhead seemed both too complex and at the same time easily circumventable. It’d take the folks who build the tools for the self-fixers almost no time to work around the hack, but the screw itself would be both expensive to manufacture and not reliable in the real world. IMHO)
Not the first time this has happened. Won’t be the last. a lot of the sites who depend on page views to drive ad revenue frankly do not care if it’s accurate or not; they just like having stuff out there they can stuff ads on. Their fan base breaks down into two groups: the folks who don’t take this crap very seriously, and the folks who take it all way too seriously. Either way, accuracy isn’t high on the list of values people demand of the sites. A few of the sites are actually pretty good, but many are simply in it for the page views and don’t care.
Back when I was with Mama Fruit, they took the rumor sites a lot more seriously than they do now. I think Apple’s come to terms with the reality that this stuff is to some degree or another going to leak, and trying to suppress it only spreads it further, so for the most part I think they try to ignore most of it and not encourage people to pay attention, which is a strategy I always suggested back in the day. Takedown notices merely focussed attention on rumors and gave them free publicity.
I also used to suggest that a way to counteract the rumor sites was through an active disinformation campaign; hit the rumor sites where it could potentially hurt with the audience you’re trying to convince to stop paying attention to them by giving the rumor sites information proven to be wrong enough that their audience writes them off. A campaigned of designed but incorrect rumors laid down on the rumor sites could create enough havoc that even the rumor sites wouldn’t know which leaks and leakers to pay attention to. At the very least, you could make their lives a bit of hell for a while and sit back and enjoy watching them twitch…
No, I never got Apple to take that idea seriously. There have been times in the last few years where I’ve wondered if they finally picked up on this idea (I still wonder about the “Apple is building their own TVs” rumor setup, since it’s a perfect thing to catch people’s attention and get them arguing over while Apple goes off and does something completely different — and notice how the rumors in this space have now shifted away from the TV back to set top boxes and content? Hmm.)
I probably shouldn’t admit this, but what the heck. Once I tweaked a couple of web pages I managed. Nothing major, just a couple of “inadvertent” links to pages that didn’t exist that were commented out. Very ambiguous stuff, just to see what happened. And like these folks, then I sat back and watched the show.
See, even then I knew there were rumor sites scraping as much of Apple as they could looking for changed pages and mistakes like this. It didn’t take long, and it hit some of the rumor sites. We got told to fix the pages, the links got pulled, and things settled down again, although every so often for a few months after that, some site or another would speculate on what those links were for. (hint: they were for making you wonder what they were for!).
And yeah, I got yelled at for doing it…. But it was more than worth it, just to watch people hyperventilate over it. Sometimes, it’s worth a kick in the pants to see the show….
(and I can still say that I know the truth about mammals.org, and you don’t… neener. And no, don’t bother asking…).
I sort of apologize for the relative quiet on the blog the last week or so. I’ve been off geeking my way through a project, and it’s borrowed most of my free time attention.
What I’ve been working on is a way to organize the data stored within my blog’s “For your Consideration” areas — lots of reviews and recommendations, but it’s a blob of data that really isn’t very useful once the initial “post to blog so the readers see it” time passes. I’ve felt for a while that better organization to make that material browsable would give it more visibility, and since it ties into amazon’s affiliate marketing, might generate some incremental revenue for the site.
(quick digression: I’ve done some minor testing over the years, and my audience seems best oriented towards Amazon or similar type advertising; I have always kept it low-key and intend to continue that, but it’d be nice if this site ultimately paid for itself, which it currently doesn’t. that’s my problem to solve, not yours. But, it goes without saying, if you like the kind of stuff I write here, and wish I’d write more, then go down to the footer and go buy yourself something on Amazon through the link. It costs you nothing, and amazon chips a few bucks into the pot for me).
I love all aspects of building sites, but if I could only do one aspect, the structure and organization the most. Figuring out how to tie everything into a usable format is both non-trivial and a lot of fun. That’s probably why I enjoyed DBA work so much, back in the day. I’ve found working out these kind of structural issues is a natural for early and quick prototyping — you have some idea how it should look, then you take your data and start pulling it together, or at least a subset of it. As you do, problems in your approach show up early (and usually, often), and you can solve it as you go along, until you either find it working, or it collapses in a heap and you tear it all apart and go back to the drawing board.
My ultimate goal is to turn “For your Consideration” into its own site. It was obvious early on that the best solution would to to use a database back end and spit the site out on demand, but I wanted to avoid building that until I knew it was worth the investment. Because of that, I’ve been exploring whether I could build it as a static site in a way I liked enough I could push public and explore how people reacted to it (or whether they ignored it, or laughed at it).
What the last few days of exploring the manual prototype has confirmed is that doing this manually doesn’t scale, even to a small scale experiment. I’m not disappointed; I had a feeling that might be the case going in. I could mitigate that somewhat with templates, but even so, I don’t see a “simple” (i.e. manual) solution working beyond 15-25 records. So if I’m going to move this forward, it’s by writing a real backend system, or coming up with another approach.
That’s the fun of doing this early prototyping; I spent a week or so of evenings exploring this. It taught me a lot about what worked with this data set as well as what didn’t, and very little real time doing the tests. It would have really sucked if I’d spent a month or so on wireframes and page design and chrome and the look and feel, only to get a week into actual implementation and hitting that “oops, we have a problem” point.
So now this one goes back on the back burner while I decide what my next steps are, or until I decide I want to go ahead and build the back end. It’s actually a fun project, but I’m not yet convinced I want to invest the time — because remember, it’s not just writing the code, it’s administering and maintaining the thing once it launches, too. Is it worth it?
Probably. But I have to think that one threw a bit…