Good writing has similarities to good UI in that you have to relate to your audience. I'm a fan of this topic and appreciate your thoughts on it. However I found your article too long for my taste and attention span. Your complaints get lost in the enormity of it all.
I was about to question your pronoun use because I thought eev.ee was a woman, but then I checked their about page and encountered this: "I respond to any pronoun; pick your favorite." Interesting approach.
Just as an aside, I checked out his Patreon page, and it looks like he earns around $850 a month for blogging. With that kind of money rolling in, you'd expect some pretty long essays. Or high quality short ones.
You don't have to go all the way to Thailand. Eastern Europe (and I do mean the part within the EU!) is livable on that salary or even as low as 500USD if you're really frugal and literally eat beans, oats and rice all day.
I wholeheartedly agree with this sentiment, despite the thoughtful responses (with which I also agree in some ways).
Writing should be clear, well-organized, and purposeful. Writing that is not, is not. Quality is self-evident.
It's not particularly worth spending a great deal of time criticizing, but it is an entirely valid point. I took very little of value from reading this in full. I say that as a product designer myself; I agree with some of the points, and a lot of what was said was correct (a lot seemed to be conjecture or just plain wrong as well...), but it just didn't come together to anything meaningful.
I don't believe that changes are being made as thoughtlessly as this article portrays. Twitter employees read the same things you and I read, you can be damn sure they're aware swapping the Moments tab caused a bunch of accidental clicks.
The article ascribes the decision to ignorance, or being bad at measuring. That doesn't feel right here. Swapping tab order is going to guarantee more people look at it, and maybe the thought process is that twitter moments is a great feature so even some accidental clickers might start using it as a result of actually seeing it for the first time.
Call it hubris or not caring about your users or whatever; the point is, all of these "dumb" decisions are being made by people whose job it is to think about them.
"My team created and implemented features XXX, YYY, and ZZZ" looks much better in some manager's performance review than "My team did NOT implement XX, YY, and ZZ, because reasons"
So the changes are very thought out, only the goals are different
Even if that's true (and I'm skeptical!) Twitter's purpose is to extract more ad revenue while not degrading the product so much that I give up and leave. That can easily be cross-purposes with what I want.
And let's not forget google's empire was at least partially built on the double charged double click on an ad. They charged for that through March 2005 iirc.
Not to mention if your median employee is using an iphone 6s plus, they don't share much about the experience with many of their users. For example, it's very clear from frustrating bits of their android app that no fitbit employees who matter use android. Similarly, no spotify employees who matter use the spotify android app...
It's a pity that there isn't a ubiquitous way to communicate to programmers features that are at risk of being removed or at risk of causing incompatibility with other software. I don't mean some document you have to look up, I mean if you use an at-risk feature, you're given a warning many years before it actually gets removed. Programmers often discover features of APIs by trial and error, not just by reading the manual.
At-risk features should include things that may not get removed but aren't supported by every platform - like .Net classes that aren't present in Wine. Sure, MS asks you not to target non-Windows platforms but in reality, users will still try to do it.
That would require the developers to know years in advance that they're going to remove something. In many cases they don't even know if they'll still be around in six months.
The tendency to just remove features without so much as a word of warning to users seems pretty popular these days. I think it is most commonly seen as part of a push to remove complexity from the program. Unfortunately this mentality can also make it seem like creating and maintaining channels that warn users of upcoming changes are unnecessary pieces of process complexity.
Of course all that is accomplished by this internal simplifying is offloading that complexity to the user who will then complain and/or seek out a way to do what they want to do on their own. Users searching for undocumented features is probably a good thing and should be encouraged. In the case of developers unwilling to communicate properly, all the users can do is try to fill in the gaps themselves by guessing and speculating on what the developers are up to. This, I don't think is such a good thing, and it's somewhat embarrassing when it happens with a social media company whose main product is a communication tool.
> Twitter recently changed “favorites” to “likes” and swapped out the star for a heart. I’m pretty used to this from Tumblr, so I was surprised by the amount of pushback. Until I saw someone make a brilliant point (which I neglected to save a link to): these tiny changes bother us because they remind us that even our very personal spaces are owned by someone else.
This is, in so many words, the main argument against the cloud and against web apps in general.
Although, with regards to things changing under your feet, even with traditional self-hosted software, a pretty big issue becomes that you must either upgrade eventually, suffer security bugs due to something being dropped from support, or (if you are using only open-source software) become a maintainer for every single piece of software you care about...
Something the desktop era didn't have to bother with. You owned the device, the software, the storage. The web is sucking the world into its cloud for reasons that seem less and less relevant.
The desktop era still required you upgrading your software often enough to patch security issues and remain inside of support. I suppose the main advantage is that you still roughly got to pick when to upgrade. Also, the time between major UI shifts was long enough that by the time you absolutely needed to move from your current version, you were buying a new desktop. Rather than having the one you'd already been using randomly "mutate" from under you...
Exactly. In a less connected world, you have more control over things. The pacing felt a bit more balanced or maybe we're still in a transitory regime where the cloud thing is not fully developped and integrated.
> I suppose the main advantage is that you still roughly got to pick when to upgrade.
I think that argument applies only when you are using someone else's cloud hosted solution like ClearBooks or SalesForce. But if you host your own cloud infrastructure on Amazon AWS or Linode and install a custom web-base product, you DO get to decide when to upgrade (apart from many other benefits of course).
Aside from simple web app UI's, something that is highly overlooked in UI, is customizeability (ability to customize, yeah that word sounds better than it looks). Only a handful of apps get this right. I've been doing UI for a while now so I notice as I used different apps. Adobe apps are pretty good, with consistent icons yet distinguishable, and highly customizeable UI that you can move around and reposition. On the other side, you have Microsoft Office UI that is just shit. I want to headbutt my monitor when I spend more time looking for a command in WORD than in Eclipse, when it's supposed to be a fucking word processor! It has no consistency in how its categorized in what seems to be random grouping, very little customization, and they take the liberty of changing drastically from one version to the next with no option to go back. I imagine the UX designers at MS like the Comcast guy from South Park massaging his nipples.
Just give the user the ability to customize a lot, and don't pay teams of UX to design specific UI that will change again and again.
On the other hand: I don't think there would be a need to customize anything if the UI was actually well thought-out and executed.
Customizing, unless it is simply about making things feel more personal (like changing the background for example), feels like fixing the UI to what it should have been, basically fixing the designer's botched job.
In other words, it shouldn't be needed.
>Just give the user the ability to customize a lot, and don't pay teams of UX to design specific UI that will change again and again.
No. That's just offloading the complexity onto the user. Not everyone wants to have to redesign their software.
The thing this reasoning overlooks is that apps are complex tools that people use in very different ways, and it doesn't make sense to force people to reinvent the wheel everytime they want a feature that your use case studies didn't predict.
How I think it should always work is:
(1) back-end layer >
(2) very customizable GUI layer >
(3) highly tuned sensible defaults and presets.
The great thing about this approach is that if you include analytics, the users to the UI testing for you: if you introduce an optional UI feature and see that a large portion of users do activate it, then you know you should make it the default or include it in some preset.
It's not so much offloading the complexity to the user, but offering a way to create your own experience in an intuitive way. You can set defaults in a sensible way in which many non-power users could just get used to, and at the same time offer intuitive ways to hide and rearrange so that power users can easily make something that is highly personalized. There's already some of this going on, like checkboxes that allow you to hide future messages, or configuring hotkeys.
30 comments
[ 3.8 ms ] story [ 42.7 ms ] threadYour post would've been better spent by suggesting a TL;DR paragraph at the top.
Writing should be clear, well-organized, and purposeful. Writing that is not, is not. Quality is self-evident.
It's not particularly worth spending a great deal of time criticizing, but it is an entirely valid point. I took very little of value from reading this in full. I say that as a product designer myself; I agree with some of the points, and a lot of what was said was correct (a lot seemed to be conjecture or just plain wrong as well...), but it just didn't come together to anything meaningful.
The article ascribes the decision to ignorance, or being bad at measuring. That doesn't feel right here. Swapping tab order is going to guarantee more people look at it, and maybe the thought process is that twitter moments is a great feature so even some accidental clickers might start using it as a result of actually seeing it for the first time.
Call it hubris or not caring about your users or whatever; the point is, all of these "dumb" decisions are being made by people whose job it is to think about them.
http://www.theverge.com/2016/2/6/10926816/twitter-employee-e...
So the changes are very thought out, only the goals are different
And let's not forget google's empire was at least partially built on the double charged double click on an ad. They charged for that through March 2005 iirc.
Not to mention if your median employee is using an iphone 6s plus, they don't share much about the experience with many of their users. For example, it's very clear from frustrating bits of their android app that no fitbit employees who matter use android. Similarly, no spotify employees who matter use the spotify android app...
At-risk features should include things that may not get removed but aren't supported by every platform - like .Net classes that aren't present in Wine. Sure, MS asks you not to target non-Windows platforms but in reality, users will still try to do it.
Of course all that is accomplished by this internal simplifying is offloading that complexity to the user who will then complain and/or seek out a way to do what they want to do on their own. Users searching for undocumented features is probably a good thing and should be encouraged. In the case of developers unwilling to communicate properly, all the users can do is try to fill in the gaps themselves by guessing and speculating on what the developers are up to. This, I don't think is such a good thing, and it's somewhat embarrassing when it happens with a social media company whose main product is a communication tool.
This is, in so many words, the main argument against the cloud and against web apps in general.
Although, with regards to things changing under your feet, even with traditional self-hosted software, a pretty big issue becomes that you must either upgrade eventually, suffer security bugs due to something being dropped from support, or (if you are using only open-source software) become a maintainer for every single piece of software you care about...
And sometimes people find UI issues bad enough to take the risk.
Just look at e.g. all the how-tos to downgrade Skype to version 6 or 4, just to avoid the horrible current UI.
Or the migration from Office 2003 to newer versions with the ribbon UI. If I'd give my users the choice, they'd all vote to downgrade.
I think that argument applies only when you are using someone else's cloud hosted solution like ClearBooks or SalesForce. But if you host your own cloud infrastructure on Amazon AWS or Linode and install a custom web-base product, you DO get to decide when to upgrade (apart from many other benefits of course).
Just give the user the ability to customize a lot, and don't pay teams of UX to design specific UI that will change again and again.
Customizing, unless it is simply about making things feel more personal (like changing the background for example), feels like fixing the UI to what it should have been, basically fixing the designer's botched job.
In other words, it shouldn't be needed.
>Just give the user the ability to customize a lot, and don't pay teams of UX to design specific UI that will change again and again.
No. That's just offloading the complexity onto the user. Not everyone wants to have to redesign their software.
How I think it should always work is:
(1) back-end layer > (2) very customizable GUI layer > (3) highly tuned sensible defaults and presets.
The great thing about this approach is that if you include analytics, the users to the UI testing for you: if you introduce an optional UI feature and see that a large portion of users do activate it, then you know you should make it the default or include it in some preset.
And I would argue that 80% of users probably use the tools in more or less the same ways anyways: hence the design in the first place.