Yikes, no, it wasn’t; I thought I was just saving it as a draft. I wonder how I did that. I meant to revise it more and then post it to the main area (not discussion).
If you click the “Create new article” button from the main page, you get a “post to” drop down that lets you choose to save to your drafts, to Less Wrong, or to Less Wrong Discussion, with your drafts being the default. This is probably what you expected.
If you click the same “Create new article” button from the discussion section, there is no drop down, and you always save directly to discussion. This is probably what happened.
(I think this difference in behaviors is unnecessarily confusing and should be removed, by making discussion act like the main page.)
Once we know how the software behaves, and how we want it to behave, and that these are different, what do we even mean by asking if the current behavior is a bug?
For a long time there was a culture among software developers that UI bugs were not “really” bugs. Now we are trying to lump UI bugs in with the rest of the things we call “bugs”.
This has the effect of making it much harder for our brains to create the false category you’re referring to, the category that makes us say “It’s just not very user friendly, not really a bug” and also tend to think “and thus it doesn’t have the property ‘needs-fixing’, of course!”
It doesn’t seem like a false category to me. “Bugs” to me are cases where the software behaves in a manner directly opposed to how the developer expected when he/she wrote it. UI flaws like this one are cases where the software behaves in a way contrary to how the user -wants- it to behave (in a UI context) but not contrary to how the developer intended.
They both should be fixed, and I agree that using the distinction to pretend UI flaws don’t need to be fixed is irresponsible, but I think it’s still a valid distinction to make.
Something about Eugine Nier’s post gave me the impression that he was saying that the software sometimes posted things even when the save option was selected. I do not know why I thought this. I agree that it is a bug.
Something about Eugine Nier’s post gave me the impression that he was saying that the software sometimes posted things even when the save option was selected.
Well according to this test, it’s doing just that.
Yikes, no, it wasn’t; I thought I was just saving it as a draft. I wonder how I did that. I meant to revise it more and then post it to the main area (not discussion).
If you click the “Create new article” button from the main page, you get a “post to” drop down that lets you choose to save to your drafts, to Less Wrong, or to Less Wrong Discussion, with your drafts being the default. This is probably what you expected.
If you click the same “Create new article” button from the discussion section, there is no drop down, and you always save directly to discussion. This is probably what happened.
(I think this difference in behaviors is unnecessarily confusing and should be removed, by making discussion act like the main page.)
http://code.google.com/p/lesswrong/issues/detail?id=242
This is a known bug. Someone should fix it.
It’s not really a bug, it’s just very non-user friendly. The button does say ‘post to discussion’, but it’s way too easy to miss.
That is a bug.
Once we know how the software behaves, and how we want it to behave, and that these are different, what do we even mean by asking if the current behavior is a bug?
For a long time there was a culture among software developers that UI bugs were not “really” bugs. Now we are trying to lump UI bugs in with the rest of the things we call “bugs”.
This has the effect of making it much harder for our brains to create the false category you’re referring to, the category that makes us say “It’s just not very user friendly, not really a bug” and also tend to think “and thus it doesn’t have the property ‘needs-fixing’, of course!”
It doesn’t seem like a false category to me. “Bugs” to me are cases where the software behaves in a manner directly opposed to how the developer expected when he/she wrote it. UI flaws like this one are cases where the software behaves in a way contrary to how the user -wants- it to behave (in a UI context) but not contrary to how the developer intended.
They both should be fixed, and I agree that using the distinction to pretend UI flaws don’t need to be fixed is irresponsible, but I think it’s still a valid distinction to make.
Possibly, what set of things we can expect next time we hear “bug”?
Something about Eugine Nier’s post gave me the impression that he was saying that the software sometimes posted things even when the save option was selected. I do not know why I thought this. I agree that it is a bug.
Well according to this test, it’s doing just that.