(Archived) TOPIC: When Feature Parity Isn't Always the End Goal

[gbarry 2,659]

We've had a lot of discussions here about the issues surrounding feature parity between clients--and more specifically between families of clients, namely desktop, mobile and the browsers (aka clippers). Many of the issues aired by users are 100% legitimate, and any amount of searching the forums shows it's something we're focused on improving with each iteration of the various clients, and that there's still work to be done.

Quite often employees wade into these discussions, making various points. One of our repeated statements is to highlight the team-based nature of our developers at Evernote. Not only are they divided by products, but they're also divided by OS. I thought a recent ReadWriteWeb article about the differences between Hello for Android and Hello for IOS did a great job revealing this part of our culture, and the goals that we're trying to achieve through this team arrangement. Money quote:

So why didn't these features come out in the iPhone version at the same time? It's deliberate. Evernote has two different teams building each version of the app, playing to the strengths of the two platforms, and learning from each other's performance.

"It's two independent teams that are really trying to talk to each other while learning from [each other's] best designs," Libin says. "It's a cooperative and friendly kind of competition. This way, [our teams] aren't doing lowest-common-denominator stuff. They're actually building full, native apps that learn from each other."

The rest of the article's worth a good look. In short, we're walking the line between parity and progress, with parity being only one side of the same coin.

[GrumpyMonkey 4,320]

We've had a lot of discussions here about the issues surrounding feature parity between clients--and more specifically between families of clients, namely desktop, mobile and the browsers (aka clippers). Many of the issues aired by users are 100% legitimate, and any amount of searching the forums shows it's something we're focused on improving with each iteration of the various clients, and that there's still work to be done.

Quite often employees wade into these discussions, making various points. One of our repeated statements is to highlight the team-based nature of our developers at Evernote. Not only are they divided by products, but they're also divided by OS. I thought a recent ReadWriteWeb article about the differences between Hello for Android and Hello for IOS did a great job revealing this part of our culture, and the goals that we're trying to achieve through this team arrangement. Money quote:

So why didn't these features come out in the iPhone version at the same time? It's deliberate. Evernote has two different teams building each version of the app, playing to the strengths of the two platforms, and learning from each other's performance.

"It's two independent teams that are really trying to talk to each other while learning from [each other's] best designs," Libin says. "It's a cooperative and friendly kind of competition. This way, [our teams] aren't doing lowest-common-denominator stuff. They're actually building full, native apps that learn from each other."

The rest of the article's worth a good look. In short, we're walking the line between parity and progress, with parity being only one side of the same coin.

Interesting article. Speaking for myself, with Evernote I want to get stuff done, and so my eye is towards productivity. On Mac, when the search explanation bar is removed, we lose global control over viewing metadata, etc. I cannot see how the competition is progressing when I look over at Windows and see every sort imaginable, search explanations, global control over metadata views, vertical list views, etc., etc. The Mac UI (in my opinion) is prettier, and the data can be searched via Spotlight, but these are the only things it can hold over Windows at the moment. It would be interesting to hear more about design philosophies if we cannot get roadmaps. Maybe I just needed to be convinced that the platform is moving in a good direction. I like changes, but I don't understand the removal of wonderful features that designers created.

The iPad is a tricky one. I really think it could be a more information rich environment (see my various posts for details), and right now it isn't terribly productive, but frankly, it is way ahead of almost any other competitor. As much as I want to see all kinds of improvements, I think we can see that it is a really nicely done. I don't feel the same sense of competition with Android here, but again, it would be interesting to hear philosophies.

As far as I am concerned, we don't need parity on every aspect. But, I consider the Windows app to be the gold standard right ow, and I'd like to see everyone moving towards that kind of functionality. It is unclear, though, that they are. I wonder if there are differences of opinion, and the roadmap has a fork in the road. Anyhow, the more productive Evernote can make Mac and iOS, the better. These are great apps, but I think they are only scratching the surface of their potential.

[JMichaelTX 4,118]

We've had a lot of discussions here about the issues surrounding feature parity between clients--and more specifically between families of clients, namely desktop, mobile and the browsers (aka clippers). Many of the issues aired by users are 100% legitimate, and any amount of searching the forums shows it's something we're focused on improving with each iteration of the various clients, and that there's still work to be done.

Geoff, thanks for putting this topic out for discussion.

As you mention, and GrumpyMonkey reinforces, there is still quite a bit of difference between the EN Win and EN Mac clients.

With rare exception, I expect both of these to have identical feature sets. And, unless there is a very well known and used UI standard for Windows or Mac, the UIs ought to be generally the same. Why? Because more and more people are using both platforms -- one at work and one at home. This includes keyboard shortcuts, where CTRL is used on Win and CMD is used on Mac. These commonalities have long been in place for shortcuts like cut, copy, paste.

I would encourage you and the EN dev teams to gather the low hanging fruit first. I think there are a number of the features missing on EN Mac that could be *relatively* simple to implement. Rather than going through a bunch of betas with multilple QA and end user testing, perhaps you could focus on these and release as one beta.

As you know the complete list of missing features is available from the link in my signature.

But I hope you don't rely on my document. I hope there is someone at EN that oversees both EN Win and EN Mac who is maintaining the *real* parity list and is working to ensure it gets done soon.

Finally, I'd like to address the EN iOS client. First, I think it should be sub-divided into the iPhone and iPad, because the screen size of these really does make a big difference. IMO, the EN iPad client should have a feature set closer to the EN desktop clients than to the EN iPhone client. Although, it is interesting that I actually like the EN iPhone Tag filter and general search better than the EN iPad.

Thanks again for your courage and willingness to address the tough issues, and to listen to your customers.

[GrumpyMonkey 4,320]

I agree with JM about the need to design for the iPad, expectations that it work more like the desktop versions (admitting strengths and weaknesses of the device will naturally result in variances), and that there are actually some better things on the iPhone (an app that has been much improved).

[peterfmartin 221]

I agree with JM about the value in having the Mac and Windows desktop apps seem more like the same product.

[jefito 5,598]

Interesting read, but i can't say that I'm much surprised over the feature parity aspect. I've always understood that to be an ever-present factor in what gets built next, but not necessarily an overriding one. Important, but not primary, that is, unless it fits in with a more important task -- I'm thinking of the addition of stacks awhile back, or the recent new multi-select behavior, which rolled out across the web, Windows and Mac clients in fairly short order.

Aside from that, multiple independent teams, operating on related but different products across a range of platforms -- that's not unfamiliar to me. Very difficult to operate all groups in lock-step, and different groups operate (learn, grow, advance) at different rates. Different UI ideas tend to grow out of different platforms, based on device and platform characteristics, but can take time to spread across other groups, while undergoing some sort of translation to a different platform's capabilities, which can make the task take even longer (which is why I was impressed by the rollout of the multi-select UI).

Overall, I thought this this was interesting in that it gave a peek into Evernote's development process, rather than just another entree into advocating the "more parity, sooner" line, which I take as a given that most of us want, at least to the extent of being as compatible as possible, but not shying away from taking advantage of native platform capabilities (which the article demonstrates in the case of access to call and message history).