The greyface, we hates it, precious!

[mskala]

Inasmuch as this is supposed to be a beta, I'm going to make beta-testing comments. Here, until I figure out where they're actually supposed to go.

The "Notifications" page is very confusing, particularly with regard to comments being sent by email and what combinations of options I am and am not allowed to select. Some forms of notification are greyed out. At least some of those I know are because they're paid-account features I don't have access to as a non-paying user; but it's not clear that that's the reason in all cases. There is no reason given on the page. I imagine the people in charge want to avoid being too pushy about encouraging me to pay, and that's nice of them, but I'd rather be told somewhere on the page "These options are unavailable because you haven't paid" instead of just having them greyed out for no visible reason. Telling me why the option doesn't work is useful information and not a commercial intrusion; not telling me is rude.

Then it also appears impossible for me to select something to be sent ONLY by email. If I uncheck the "notify me in my inbox" box, then the email box gets greyed out. Is it the case that I'm just not allowed to receive notifications by email only? That seems gratuitous if it's the case, and it seems especially odd in light of the next item: There are a few notifications marked with an asterisk pointing at a note saying they are only available by email in the first place. But I can still check the box saying that I want them in my inbox, and indeed, I must do that in order to be able to control the box saying whether I want them by email.

My suggestion: Separate and fully independent check boxes for email and inbox notification, not for inbox and "email in addition." No greying-out ever. Check boxes for options I'm not allowed to select should not appear at all, and I should be told why. If there is a notification I might want that I'm not allowed to have, it should still appear, ungreyed but with no check boxes, and it should have a tasteful note right on the description line (not buried in an asterisk reference at the bottom) explaining why I'm not allowed to have it. For instance, a description might read "Someone votes in a poll I posted (paid-account feature)".

BONUS GRIPE: Now as I attempt to post this, the option I want to use of "Everyone (public)" in "Show this entry to:" is greyed out. Is that because I can't make public entries while DW is in beta? Is it because my choice of making "Access list" the default for new postings, means I'm actually not allowed to post public entries anymore? Who knows? Note that even if I have access to that information elsewhere, for instance in an FAQ, it's still a problem because I don't have the information right here. What I have right here is an unpleasant surprise and a reason to go away. Greying out is almost always the Wrong Thing for a system to do. If an option isn't available, I want to be told why, right then and there.

ETA: having posted that with "Access list" as the access level, I find that immediately afterward I can edit the entry and change its access to "Everyone (Public)". I think that means the grey-out during initial posting must have been a bug, because I can't see any way this behaviour would be intentional.

Comments

[denise]

dw_suggestions is a good place to go for leaving suggestions, and bugs right now go to the comments to dw_news until we get a better reporting process. (You can also check our Bugzilla!)

Quick overview:

-- the inbox/email thing is because LJ migrated to running all comments through the notifier system, which doesn't have a way to opt out of getting comments to the inbox, and we forked from that code. (Some people on LJ are still using the old legacy system, which is why you might not have that behavior.) We're planning on fixing it up so that you can (for instance) auto-designate certain things to go to the trash and auto-empty the trash at certain intervals, just haven't gotten to it yet.

-- Logged a bug to indicate that greyed-out options on the notifications page are greyed-out because the account type doesn't permit use, ta!

-- With the update page, if you've set a minimum security, you can't post an entry with a less restrictive security without posting & editing it. This is so an accidental change in the drop-down doesn't do something the user isn't expecting and expose something they wanted private, so it's a feature, not a bug. (LJ does it that way, too.)

[mskala]

I wish I could set a real default security level instead of a minimum - much as the system allows for things like comment screening. I note that the configuration page calls the existing feature "Default Entry Security", although the description does use the word "minimum." I set what I thought was a default, for convenience because it's the level I expect I will want for most of my postings; but if it means I need to do a separate "edit" operation to make any public postings, then its value to me is not positive. I'd rather take my chances of accidentally overriding the default, and I'm not particularly interested in what Livejournal does. If someone else wants to not have a choice, that's a reasonable thing for them to want, but it's not what I want.

It's also a violation of least-surprise, because the similar settings for comment screening and comment availability really are defaults instead of minima. (Though, interestingly, the configuration page doesn't say "default" for these and implies they will be global to all postings.)

In any case if there are features disabled, I'd like it to be obvious why, instead of the interface just indicating "You can't do that." For instance, in this case it'd be nice to have a line of text under the selection box saying "Public does not appear because you chose Access List as your minimum on [link]this configuration page." And note that that's "does not appear" - having it appear but greyed out is almost invariably the Wrong Thing.

[sophie]

This is so an accidental change in the drop-down doesn't do something the user isn't expecting and expose something they wanted private, so it's a feature, not a bug.

To clarify (and you'll know this, Rah, but just making sure it's known), that's not the initial reason why they're greyed out. LJ had it so that if you set a minimum security level, you *couldn't* select anything more public than that on a first post, but the options weren't greyed out, which caused confusion. The greying out was to bring the user interface in line with what already happened in the backend and prevent the confusion from *that*.

I hate the way this works, and I think mskala's reply makes sense, instead that I think it should go one further and have a separate option for "Default Posting Level". That's because there's no way to specify that at the moment for clients and no way to get that information, either, which means that clients are forced to default to an option by themselves - either public, or something you specify.

I would dearly love to see this fixed, and I'd be happy to code it, too. The only problem is it breaks expected behaviour for existing clients, which could be a problem, especially when crossposting client-side. :/

[mskala]

Those options seem to be OPTION tags inside a SELECT tag on the HTML form. What's wrong with putting the SELECTED attribute on the one corresponding to the default selection? That is documented by W3C as the correct way of specifying a default in a SELECT dropdown, and in fact what the system currently does (leaving no option pre-selected) is what W3C says page authors "should" not do. I don't think it'd be too hard to also make the default setting be the first one listed, for browsers that might not pay attention to the SELECTED attribute. It shouldn't be any harder than the current behaviour of setting an attribute to grey out lower-than-minimum levels. Obviously there will be some browsers in the world that ignore both hints, but I think it's reasonable to expect a browser to do the right thing if you implement them both, and it doesn't seem like that would be hard to do.

[sophie]

There's nothing wrong with that.

There are many advantages of having a 'default' option over having it auto-selected.

* It's possible to post to another journal from the update page by supplying a username and password without having to log in first, and indeed, the update page can even be used when logged out. In this scenario a 'default' option is the only thing that makes sense.

* On the backend, being able to accept 'default' as an option (which it would then translate to the appropriate security level before saving the post) would mean that other non-Web clients can use that easily. True, it doesn't have to show on the Web frontend, but that brings me to another reason:

* The other journal options on the update page all have a "Journal Default" option, too. It would be nice for consistency, too.

[mskala]

Oh, I see - by "client" you mean "LJ-protocol client," not "Web browser." I don't know what the right answer is in that case; I don't know how flexible the protocol for those clients is or isn't.