Live data from Hacker News

Being Slow to Criticise

solipsys.co.uk

31–40 of 76 posts

Re: Being Slow to Criticise

#31

There's a difference between being slow to criticize and completely withholding criticism. I agree that software is written by smart people, working under constraints. But so what? If it sucks, it sucks, and we should call it out as such! How will we ever improve anything if we can't highlight what's wrong with the current solution? My go-to example in this regard is the Microsoft Office ribbon. I remember, when the…

I personally like Ribbon over rows and rows of small icons without labels. I think of Ribbons like tabs that organizes the buttons that makes sense together.

But I'm not a power Office user and that's just my preference.

Re: Being Slow to Criticise

#32

There's a difference between being slow to criticize and completely withholding criticism. I agree that software is written by smart people, working under constraints. But so what? If it sucks, it sucks, and we should call it out as such! How will we ever improve anything if we can't highlight what's wrong with the current solution? My go-to example in this regard is the Microsoft Office ribbon. I remember, when the…

I personally like Ribbon over rows and rows of small icons without labels. I think of Ribbons like tabs that organizes the buttons that makes sense together. But I'm not a power Office user and that's just my preference.

Would you spend a little time sharing stories about other things you prefer?

Re: Being Slow to Criticise

#33
Hum... The article puts no effort on determining how much work went into that comment's assessment and how useful it was to people looking into invest some effort on migrating and learning how to use it.

Re: Being Slow to Criticise

#34

There's a difference between being slow to criticize and completely withholding criticism. I agree that software is written by smart people, working under constraints. But so what? If it sucks, it sucks, and we should call it out as such! How will we ever improve anything if we can't highlight what's wrong with the current solution? My go-to example in this regard is the Microsoft Office ribbon. I remember, when the…

I personally like Ribbon over rows and rows of small icons without labels. I think of Ribbons like tabs that organizes the buttons that makes sense together. But I'm not a power Office user and that's just my preference.

The ribbon didn't replace rows and rows of small icons without labels. It replaced a hierarchical menu. Now, did the hierarchical menu have flaws? It did, insofar as it was rather forbidding to explore, and as a result, new users had trouble finding functionality by clicking around. That was the use case that the Ribbon sought to address.

What the designers of the ribbon did not understand was that users have other ways to find functionality. They could look up functionality on the Internet. There were even physical books which told you which specific menu to click on for a particular function.

What the ribbon did was instantly render all those resources useless. Moreover, by attempting to constantly surface different controls based upon the context of the current task, the ribbon made it extremely difficult to make new resources and tutorials. You could make a tutorial with screenshots, only to have users come to you with screens that look nothing like your screenshot, because they just happened to be highlighting a slightly different element.

Re: Being Slow to Criticise

#35

There's a difference between being slow to criticize and completely withholding criticism. I agree that software is written by smart people, working under constraints. But so what? If it sucks, it sucks, and we should call it out as such! How will we ever improve anything if we can't highlight what's wrong with the current solution? My go-to example in this regard is the Microsoft Office ribbon. I remember, when the…

If you described how you saw some users struggle, that would be useful observation. Saying "it sucks" is a judgement call that adds no useful information. There are always people who dislike things, so one more stranger saying they dislike it doesn't add anything.

Re: Being Slow to Criticise

#37

There's a difference between being slow to criticize and completely withholding criticism. I agree that software is written by smart people, working under constraints. But so what? If it sucks, it sucks, and we should call it out as such! How will we ever improve anything if we can't highlight what's wrong with the current solution? My go-to example in this regard is the Microsoft Office ribbon. I remember, when the…

If you described how you saw some users struggle, that would be useful observation. Saying "it sucks" is a judgement call that adds no useful information. There are always people who dislike things, so one more stranger saying they dislike it doesn't add anything.

Sometimes people come to the correct conclusion without knowing how. And sometimes people come to the wrong conclusion with a painfully detailed process that really just led them astray. So maybe gut-level reactions shouldn't always be dismissed, and detailed reactions shouldn't always be held above gut level ones.

Re: Being Slow to Criticise

#38

I recently had a small rant on Twitter about a certain web technology; I used the word "crap." One of the main authors of the tech spotted my post and replied saying my rant was offensive and that they had worked hard and done the best they could. It had been a long time since I felt that much shame in myself. It could have been me pouring myself into something and then the other guy calls it crap.

No post body was provided.

Re: Being Slow to Criticise

#39

There's a difference between being slow to criticize and completely withholding criticism. I agree that software is written by smart people, working under constraints. But so what? If it sucks, it sucks, and we should call it out as such! How will we ever improve anything if we can't highlight what's wrong with the current solution? My go-to example in this regard is the Microsoft Office ribbon. I remember, when the…

I think there's two important aspects of this article:

1) Assume the people who wrote the code aren't stupid.

2) Be nice to developers

Point #1 is valid, because yes a lot of times intention is difficult to suss out and the guy who wrote it might have known something you didn't, or maybe the circumstances were different when it was written.

Point #2 is just wrong, it goes against the entire principle of Egoless Programming. Like you said about Ribbon, if it sucks you need to just admit it and either make it better or scrap it. It's just software, people don't need to incorporate every bug they write into their personal feelings of self-worth. If anything developers should embrace criticism, there might be lessons there to learn.

Re: Being Slow to Criticise

#40

There's a difference between being slow to criticize and completely withholding criticism. I agree that software is written by smart people, working under constraints. But so what? If it sucks, it sucks, and we should call it out as such! How will we ever improve anything if we can't highlight what's wrong with the current solution? My go-to example in this regard is the Microsoft Office ribbon. I remember, when the…

Maybe my memory is failing me, but I don't recall MS adopting the ribbon because it was better (even if they said it was). The purpose was to patent the ribbon UI, get it in front of as many people as possible while MS had a monopoly, and get it established as the "right" interface. That would make open source competition inferior and would allow MS to charge a tax on commercial competitors.

For example: https://www.infoq.com/news/2018/02/Ribbon-UI/

Post reply on HN