denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
Denise ([staff profile] denise) wrote in [site community profile] dw_news2012-03-17 01:42 am

Dreamwidth Update: 17 Mar 2012

Hello, Dreamwidth! As usual, I bring you apologies for the long gap since the last [site community profile] dw_news post (there is always something to prevent the good long chunk of time I need to write one, but I'm sick and tired of doing things that won't pan out for ages by now!) and a whole slew of interesting things to discuss and share.

Behind the cut, we bring you:

* Development update
* Text Captcha
* Icon-Related Changes
* A note from the antispam team
* Custom dictionary expansion
* Default styles poll
* Dreamwidth Arts & Culture - "Delights"




Development update



The period since last we've spoken has seen two code tours. (For our new neighbors: the "code tour" is the regular listing of all the changes, improvements, and bugfixes we've added to the codebase during the period in question.)

First off, there's 1 Feb 2012 through 22 Feb 2012, all of which are now live on the site and many of which you may have noticed already. In addition to some changes that I'll get to in a few sections, this includes:

* Opening up the Support History page to everyone, so if you're looking for a support request you filed ages ago, you can locate it again. (This page isn't linked on the main support pages yet -- we're still trying to figure out where to put it.)

* The ability to only track a single user's posts to a community (instead of tracking the community as a whole). This option now shows whenever you hit the "track this" icon or link for a community (as a whole) or an entry in a community. (And, while we were at it, we rearranged the options for tracking an entry to make them a little less overwhelming.) (Edited 3/21, I'd forgotten the exact implementation there!)

[I should point out, by the way, that the bug for adding that feature was bug #8 -- logged well before we actually opened our doors -- and was also the last single-digit bug we had remaining. Hooray for resolving older bugs!]

* Displaying the number of screened comments on entries with screened comments (to those who have the ability to see the screened comments on those entries, I mean) -- previously, if you had 2000 comments on an entry but only 20 were visible, the comment count on the entry would say "20 comments". Now, it will instead say "20 visible | 1980 screened comments". For now this is only available on site-skinned comment pages (including the light mode entry view), but now that the hard part's done, we can do the tedious part of enabling it in individual styles' custom comment pages.

Then, we have the code tour for 22 Feb - 13 March. Most of these improvements aren't available on the live site yet, with the exception of the FAQ changes that were made -- they're still in testing. But, you can take a look to see the interesting stuff that's coming up.


Text Captcha



One major change we've made recently is to the "human test" shown across the site when we want to make sure that it's an actual person on the other end of the keyboard, rather than a spambot. Previously, we used a service known as "reCAPTCHA" -- this is the familiar "type the words you see on your screen" image-based human test most people are familiar with from many, many other sites.

Those human tests are very bad for accessibility, though -- they're impossible for people with low vision or screenreader users to solve (the service does have an audio version of the test, but those are widely considered to be much more difficult than the visual version). The reCAPTCHA service has been making their human tests more and more difficult lately, because spambots have gotten better and better at solving them. And, finally, we'd been getting multiple (and annoying) reports of people being unable to load the human test at all, because their computers couldn't contact the service.

So, for sitewide use, we've replaced reCAPTCHA with a new service known as "Text Captcha", which asks you to solve a very basic question -- something like, "Tomorrow is Sunday. If this is true, what day is today?" They're written to be very simple for humans to solve, and harder for computers to solve. The advantage is that they can be solved much more easily by screenreader users, and it eliminates a very bad accessibility barrier. (Accessibility is one of our prime commitments -- we want Dreamwidth to be usable by anybody.)

The disadvantage of text captchas is that they're harder for non-English speakers to solve, so it is a slight tradeoff. Given how simple the questions are, though, translation software should be able to handle them fairly well, and Dreamwidth itself isn't translated into other languages (for many, many reasons), so it's a tradeoff we were comfortable making.

We know that many of you use the human test for commenting in your journal (for anonymous comments only or for all comments) to minimize spam risk, though, and your audience may be different than the audience for Dreamwidth as a whole -- if you have multiple non-English-speaking commenters and no readers who are screenreader users or who have low vision, you may want to go back to using the image-based human test. If that's the case, go to the Privacy tab of Account Settings and look for the "Anti-Spam Type" setting. You can choose between text-based and image-based human tests for your journal. (It won't change which version you see elsewhere on the site, but it will hold for your journal.)


Icon Changes



As many people noticed, our last code push changed a few things about how icons are displayed, and there are a few more changes coming.

Multiple Pages of Icons

The page that shows all of an account's icons -- username.dreamwidth.org/icons -- is now paginated. Each page will show 50 icons to a page, and there's a navigation box to move forward and backward in the list. (There's also a "view all" link, if you'd still like to see all the icons at once; right now you can't easily get to the "all icons" page when sorted by keyword order rather than upload order, but that will be fixed with the next code push.)

This was done for several reasons. First, we're in the process of letting people choose to show the icon page in journal styles (rather than only being available in site skin) if they'd like, which is part of a major and ongoing effort to make everything that has to do with your journal display in your journal style. (The other major effort there involves the profile page.)

Second, one of the pieces of feedback we hear most often is that it's very, very painful to view and manage icons once you get up over a certain number. Because we're working on a way to let people buy more icon slots if they want (more about that in a second), fixing up icon management and display for large numbers of icons was a pre-requisite. Many people with slow connections, older computers, or mobile browsers were already having trouble loading icon pages past a certain number of icons, and it will only get worse as we allow people to have more icon slots! (Watch for further optimization efforts in the next few months as we gear up to releasing icon add-ons.)

Changes in hover text

With the last code push, we changed how hover text on icons is formed, so that instead of being "username, icon keyword" it is now username, keyword, and description. (Well, that's a slight inaccuracy: currently it's username, keyword, comment, and description. Seeing it in action, and based on feedback we've received, it's clear that the comment field shouldn't be there; it will be removed with the next code push, along with fixing a bug that's causing all keywords for each icon to display instead of only the keyword used to select the icon.)

We've been going around and around in circles on this since, I kid you not, 2010. The reason for making the change: the Description field on the icon management page is intended for people to write descriptions of the icon, which will be read to people who use screenreaders and shown to people who are using text-only browsers. So many people use icons as an additional channel of metadata about their comments, or as a hint about how their comment should be interpreted, and that information was totally lost to people who weren't browsing or weren't able to browse the site visually. The Description field was one of the first accessibility improvements we made to the site (and a lot of people who don't browse the site visually have told us they really, really appreciate it!)

The problem was, most browser make it nearly impossible for someone to get at the "alt text" (the text displayed in lieu of an image) without viewing the source of the page. Many people weren't even aware of the reason for that field being there. By putting the description into the hover text (which is shown in graphical browsers) as well as the alt text (which isn't), we hope to make it more clear to everyone what the description field is used for, thus encouraging more people to fill out descriptions for their icons.

Similar changes were made to (HTML) comment notification emails -- adding in the description and the keywords used for each icon -- to sync with the way icons are displayed on the site.

All of thse changes are to follow one of the core "best practices" of accessibility: there should be no information that is only available to users who are accessing your site in one particular way. (For instance: there should be no information only available to sighted users, or only to people who can use the mouse to hover, or only to people who are able to use the keyboard, etc.) We know we're not perfect on this yet -- there's still a few things that you need to be able to mouse in order to use, although we've nearly gotten to a point where we're happy with screenreader users' experience -- but accessibility for people with disabilities is one of our key values as a site, and we'll keep chipping away at the problem.

Icon add-ons brainstorming

As I mentioned up there, we are in the process of designing the icon add-on system for paid account holders to buy more icon slots if they feel they don't have enough!

Our current thoughts on how it will work, and our questions for you about how you would want it to work, are in the Brainstorming: icon add-ons post in [site community profile] dw_biz. If this is something you're interested in, head on over there and give it a read-through, then weigh in.

(I'm actually trying my hand at coding this one myself. Meep.)



A message from the antispam team



The increase in traffic and usage we've been seeing in the past few months -- we've nearly tripled our regular traffic over the past four months -- has brought with it a corresponding increase in spam, since spammers gravitate more towards more-active forums. It's thanks to the tireless efforts of our antispam team (who enjoy smacking spammers with a visceral glee) that we've been able to hold off the incursions so far -- spammers choose targets based not only on the service's activity and search engine visibility, but also on how well the service is protected and how quickly spam is removed.

If you receive spam comments, delete them and mark them as spam, whether they came from a logged-in user or an anonymous user. This is the best and fastest way to report spam and the way that will result in the quickest handling of spammers. It's tempting to report spammers spamming from a Dreamwidth account to the Terms of Service team, and if you do that they will still get handled, but the antispam system is still faster!

Please don't mark things as spam if they're not actually spam -- which is defined as commercial promotion, unwanted bulk solicitation, or automated gibberish (used to test a site's search engine visibility). Marking other things as spam only wastes the time and energy of the antispam team and prevents them from handling actual spam as quickly as they otherwise could.

Things that are not spam are generally aimed at a specific account or community and unique to that account or community: a single individual leaving comments that are critical of you or your community; a group of multiple individuals trying to disrupt your discussion with low-volume but annoying comments; a single individual leaving comments that are unpleasant, obnoxious, outrageous, or otherwise antisocial; low-volume trolling; comments designed to "page break", contain large/disgusting images, or otherwise disrupt the discussion; other general acts of asspimplehood. All of those things are definitely obnoxious and unwanted, but they aren't spam. They can be dealt with by turning on the "human test" (which may discourage the casual asspimple commenter), enabling comment IP logging, and in the worst cases by disabling anonymous comments and banning logged-in commenters whose comments you don't want.

If you're in doubt as to whether something is a wider automated spam campaign or if there's a human behind it trying to disrupt your individual account or community, it's okay to report it anyway -- there'll always be some false alarms and sometimes it's hard to tell the difference between one person doing ill-advised self-promotion manually and an automated spam campaign. Still, you can help us fight automated spam by making sure that you only report things that are spam.


Custom dictionary expansion



Way back in the dawn of Dreamwidth, we made a few changes that would let us define custom words in the dictionary used for on-site spellchecking. (This is the system that you can access when you preview and spellcheck your comment, not the computer-specific system that highlights potentially misspelled words as you type them with squiggles/underlines/highlights/other as-you-type indicators.) At the time we added a bunch of words we thought should be in the dictionary and then said we'd come back to the question after a few years once our users had had a chance to build up more site-specific vocabulary.

We're marching steadily towards DW's third anniversary (oh my goodness where has the time gone?), so it's time to re-visit the question! If you've noticed anything missing from the spellcheck dictionary, take a second to pop over to the Custom Dictionary brainstorming entry on our development wiki and add your contributions. (Editing is limited to logged-in users, but you can log in with your Dreamwidth URL using OpenID -- just enter your journal's address, such as http://denise.dreamwidth.org.)

We may not add every suggestion to the dictionary -- there are performance implications to a large custom dictionary -- but the wider the initial list, the better.


Default styles poll



Another thing we do here now and then is poll all y'all about what the default style and theme for newly-created accounts should be. (This doesn't prevent people from changing their styles, and it doesn't change the style for people who have already created their accounts; it only specifies what style should be used for newly-created accounts.)

It's been a while since we've done that -- the last poll was October of 2010, in which the default theme was selected as Neutral Good for the Practicality style. We've added a shitpot (that's a technical term) of new themes and styles since then, thanks to the hard work of the [site community profile] dreamscapes crew, so it's more than time to pick a new default.

Below please find a poll for which style you think should be the default style. Once we've chosen that, the next news post will include a poll with all the themes for the winning style. Once that poll's had a chance to run for a bit, that theme will be set to the new default theme.

(In this poll, I have removed Practicality, Skittlish Dreams, Transmogrified, and Negatives, all of which have previously been the default styles, so that the new default style will be one that hasn't been featured before! I've also removed EasyRead and Tabula Rasa, which are specialist styles designed for accessibility needs and for CSS skinning, respectively, and Zesty, which is a legacy style from our early closed-beta days.)

You can view all the base styles all at once. Each style in the poll is linked to all the themes available for each style. We hope you enjoy the chance to look through all the awesome styles and themes we've been adding!

Poll #9894 The 2012 Default Style Poll
This poll is anonymous.
Open to: Registered Users, detailed results viewable to: All, participants: 467

Which base style should be the default style for newly-created accounts?

View Answers

Abstractia
69 (14.8%)

Bases
11 (2.4%)

Basic Boxes
13 (2.8%)

Blanket
12 (2.6%)

Boxes and Borders
11 (2.4%)

Brittle
15 (3.2%)

ColorSide
10 (2.1%)

Compartamentalize
18 (3.9%)

Crisped
24 (5.1%)

Crossroads
20 (4.3%)

Drifting
7 (1.5%)

Dusty Foot
31 (6.6%)

Five AM
91 (19.5%)

Fluid Measure
15 (3.2%)

Funky Circles
18 (3.9%)

Marginless
6 (1.3%)

Modish
4 (0.9%)

Modular
26 (5.6%)

Nouveau Oleanders
9 (1.9%)

Paletteable
9 (1.9%)

Refried Tablet
10 (2.1%)

Stepping Stones
3 (0.6%)

Sunday Morning
11 (2.4%)

Tranquility III
24 (5.1%)




Arts & Culture - "Delights"



As many of you may remember, previously I've tried to include a section in news updates highlighting some of the awesomely creative things that DW users make, do, create, and share. I haven't been able to do this for a while, because it's an incredibly resource-intensive thing that I just haven't been able to keep up, but I've really missed having it -- DW users are doing some amazing things out there and I love seeing them!

But! Fear not, because [personal profile] pinesandmaples has volunteered to assemble a "Dreamwidth Arts and Culture" section in news posts. (And if you have something awesome that you've made/done/created/shared, drop her a PM!) I'll turn it over:

"Delights"
My theme this week is inspired by my recent reading assignments in early Quaker theology. Some of Dorothy White's words in an early tract pushed me to "look to the small delights, enjoy the world we have."

  • [personal profile] michiru tells a delightful little story of beans in her comic [community profile] chibibeans. Recommended is Prince of Tennis bean!

  • [personal profile] sneezer222 posted the only picture of snow that has ever caused my little Southern heart to squeal with glee, captured with only the flash and unaltered! The gentle glow of the falling flakes makes this view a sweet taste of wonderland.

  • [personal profile] noelleno offers art that shows a dramatic range of facial expression via very simple lines. Follow the progression down the post; don't just take my word for it!

  • The team at [personal profile] namsan_daily posted a photograph and description of hiking around Seoul, South Korea. Their post is a mini-vacation, a little jump away.

  • [personal profile] lorres shared one of her recent knitting projects and the process it took to get there her knitting blog. The cohesive neutrals were no accident, and they slide together so well. Beautiful.

  • [personal profile] argentumlupine blinded me with some mad science! A rad crash course on electric circuits basics (complete with diagrams!) makes all of these visual delights possible. I love electricity.

  • *

    And that's it from us for another update! As always, if you're having problems with Dreamwidth, Support can help you; for notices of site problems and downtime, check the Twitter status page; if you've got an idea to make the site better, you can make a suggestion.

    We'll see you in a few weeks for our next update. (And oh goodness I just previewed this entry and noticed that the styles poll actually looked like a poll in the preview. I always forget how many absolutely awesome little fixes we've done until I see them in action.)
    the: (m. fassbender ☛ ( you go squirrel girl ))

    [personal profile] the 2012-03-17 06:37 am (UTC)(link)
    oh i didn't know they could be that long! wowsers. yes that would be unwieldy. and certainly i realise people use them differently ( my name isn't actually drogue, for instance ) so i figured that would factor in. apologies for forcing you to rehash something that's come up a bunch before. like i said, i was just curious as to your reasoning, since i know the dw team always makes, well, smart and logical decisions based on all the evidence and opinion. i can't even begin to fathom some of the stuff you guys take into account but i'm always interested to know what it is. thank you for getting back to me and for all your hard work!
    sends: (peer ☾ On the day you left...)

    [personal profile] sends 2012-03-17 07:33 am (UTC)(link)
    Can the display names really be that long?

    I recently tried to make the display name for one of my journals "Intelligence program CTN 0452-9 'Cortana'" and was told it was too long to use. It was actually that length on LJ, which surprised me since the reason for not allowing the display names to show on hover was because they were supposed to be able to be that much longer. I've ended up getting along fine without the display name hover (though I'd still very much like it, personally) but it strikes me as odd that I wouldn't be able to use that.
    inabook: (Default)

    [personal profile] inabook 2012-03-17 08:13 am (UTC)(link)
    I'm with the other people requesting that the "name" field replace username on hover text. It seems to me that knowing the "name" would increase accessibility, because the person's username is already present, and knowing the "name" of a person can be very important/useful for all kinds of interaction on the site (not just limited to RP.)

    The main concern seems to be the length of the name, but I just tested it and the limit for the name field is 50 characters. That really doesn't seem that unbearably long even for a person who must fill out every bit of space they have...

    Regardless of this issue, I'm very pleased with Dreamwidth and the experience I've had on the site so far. Thank you very much for your hard work and effort.
    ana: (pic#1149173)

    [personal profile] ana 2012-03-17 09:41 am (UTC)(link)
    It seems to me that knowing the "name" would increase accessibility, because the person's username is already present ...

    This was my thought as well! I am speaking as an RPer primarily, where I would really appreciate the name in hover, but also in personal interactions it's nice to know what name people prefer to be called without going to their profile page like I've been doing on DW.

    It seems like a tiny thing but copy-pasting names into hundreds of icons worth of descriptions is an exhausting solution. I know nothing about screen-readers, though, or what the majority of users put in the name field.

    Your explanations are always appreciated, Denise. ♥
    inabook: (over the shoulder)

    [personal profile] inabook 2012-03-17 12:26 pm (UTC)(link)
    And in a similar vein, for the argument that some don't use the name field for their name - more people do use the "name" field for their name than use the "Description" field for their name. It seems to make more sense to have the name field show up than expect everyone on the site to realize they should put their name in their descriptions.
    ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)

    [personal profile] ninetydegrees 2012-03-17 12:27 pm (UTC)(link)
    It seems to me that knowing the "name" would increase accessibility, because the person's username is already present

    If you're on a screenreader, usernames are printed later in the flow of things. Userpics come first so you get to know who posted entries/comments sooner if usernames are in the description field.

    That really doesn't seem that unbearably long even for a person who must fill out every bit of space they have...

    50 characters isn't long when it provides useful info; as Denise explained above, the name field is used in many different ways including not to display any kind of 'name'.

    /my2cents
    inabook: (curious princess)

    [personal profile] inabook 2012-03-17 12:36 pm (UTC)(link)
    But it's a field that's intended to be useful info, thus it being "Name." Whether people use it for that or not is up to them. I'm sure people with screenreaders also may wish to know what to call the person they are responding to. Right now they'd have to open up a profile page and check the name box (and then profile, if the name box isn't filled in) - which would be even more time-consuming, wouldn't it? Especially if the name box actually *is* filled.

    Basically, it seems overly silly to deny many people the useful name info because a few people like to put quotes instead of names. Not everyone uses the description fields correctly either, but yet they exist and can be useful when they do.
    ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)

    [personal profile] ninetydegrees 2012-03-17 12:42 pm (UTC)(link)
    I'm sure people with screenreaders also may wish to know what to call the person they are responding to.

    In addition to having the name field actually filled with any sort of name, this supposes screenreader users want to do that. I'd never call you Estelle for example. To me, you're inabook because usernames have more value and are more useful for me and I never look at names, wherever they are. It would be easy to decide what's actually useful info if everybody was using the site the same way but we don't. If you add to that that nobody can force users to use the 'name' field in the way you intend it, I sincerely doubt names would be more useful than usernames for a majority of users.
    Edited 2012-03-17 12:44 (UTC)
    inabook: (Moe)

    [personal profile] inabook 2012-03-17 12:47 pm (UTC)(link)
    But the key word is "may." I "may" not care about your icon keywords or descriptions either, but I can still see them... Many people do find the name to be useful, so I'm merely arguing the position that there doesn't seem to be harm in adding it.

    Of course, that's provided that it's accessible. The real test would be to ask a person with a screenreader which system is easier or whether it matters, rather than speaking only in hypotheticals.
    ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)

    [personal profile] ninetydegrees 2012-03-17 01:09 pm (UTC)(link)
    The real test would be to ask a person with a screenreader which system is easier or whether it matters, rather than speaking only in hypotheticals.

    I believe this change is actually the result of several discussions with screenreader users. You can find them on dw_accessibility.
    whitelighter: (NCIS » :|a?)

    [personal profile] whitelighter 2012-03-17 08:25 am (UTC)(link)
    Along with what users like [personal profile] sends and [personal profile] madheroking have said, I think it should be worth asking that if the userbase wanting a name field hover-text is so small... is it possible to add the option into the admin_console to let those of us that want it seek it out, while those who don't care won't know it exists?

    That would lessen on the options fatigue, but still be available to those of us who are generally all in the same circle (roleplay) and have already established ways of spreading this information around to everyone who would care. In the same vein, it would be kind of nice to be able to take out the hover for descriptions, possibly also with an admin_console command. It just makes some hover-texts very long in the way I think you guys were trying to prevent, and giving an opt-out if it's not too much trouble would be incredibly lovely.
    glampuss: (Default)

    [personal profile] glampuss 2012-03-17 08:46 am (UTC)(link)
    255 characters does seem rather long for a name field. Perhaps shortening the number of characters available would make it less unwieldy in the hover box?

    Also, since a lot of people are using it to put in a saying or quip, maybe the profile could have another field that has a longer character limit and is called something like "catch phrase" or "motto"? The would then allow people to put in quotes as well as names.
    redbird: closeup of me drinking tea (Default)

    [personal profile] redbird 2012-03-17 11:57 am (UTC)(link)
    A lot of my friends are either leaving the "name" field the same as the username (because they think of that as their real name, or it's the identity they want shared here—and I do know people whose name here and/or on LiveJournal matches the name they get phone bills under) or using it to play with. Mine for a while was a silly math-based pun; a friend of mine swaps from one silly thing to the next, none of them being what any of us call this person.
    fools_journey: (hmm?)

    [personal profile] fools_journey 2012-03-17 01:27 pm (UTC)(link)
    I can understand not including a display name in the alt text for icons or in any sort of hover-over for icons, both for the convenience of screenreaders and because if you're just presented with an icon, for example, it makes sense that the unique screen name be the first thing you want to identify with it. However, that said, a screen name is not the only means by which - or even necessarily the primary means by which - people identify their journals here.

    Consequently, would a possible useful compromise be to include display names in the hover text for usernames?

    When I'm hovering-over a username, I'm already looking at the username. I don't need to see the username again, and I'm going to add to the chorus of people who would, if this option were available, use it to see what name an account is actually listed under.

    Also is not the display name meant to be a name? Even if there are people who use it for other purposes, why should that bar people who wish to use it for its intended purpose from getting any use out of it? By that logic, why should we have the 'description' field for icons displayed at all, when a lot of people (in my experience, which I admit is pretty limited) either don't bother to fill it out or put quotes and things there instead of a description of the icon. I am also guilty of this.

    That aside, when people are using a display name for its intended purpose, we have to go to their profiles to see it. This seems to me (though I admit I am not very knowledgeable about what things besides icons take the most work from the servers) to be unnecessary work on our fronts and unnecessary extra traffic for you guys, as it means instead of a single data field being loaded on an already loaded page, instead it involves loading an entirely new page.
    Edited 2012-03-17 13:32 (UTC)
    ceesoo: Howard Link's face shooped onto Zelda!Link (Link} he come to town)

    [personal profile] ceesoo 2012-03-17 08:42 pm (UTC)(link)
    I was making visuals of the ideas people were suggesting so... don't mind me, just leaving this here...

    ceesoo: Ranma and P-chan (Ranma} Pajamarama)

    [personal profile] ceesoo 2012-03-17 10:11 pm (UTC)(link)
    I imagine this is probably something to take over to the suggestions comm, but you seem to get asked the username vs. display name thing every update and I don't know if you want to deal with it in two places...? So just.. COMMENTING HERE FOR NOW /o/ But yeah, I really don't think this is a thing that can just be left as-is as long as a good chunk of users want to see the display name somewhere easy to access on the comment pages.

    Anyway, this idea by [personal profile] fools_journey and this idea by [personal profile] darjeeling I assume both have accessibility issues? If, as the original post says, the aim is to make sure all users--whether they're on visual browsers, screenreaders, or mobile devices--are able to access the same information, then obviously hover-over style solutions like a title/tool-tip on the username link or a new piece of info on the contextual hover menu won't be accessible to everyone.

    Sooo, I was thinking, is it too cluttered to put the display name next to the username on the comment bar? Like this:
    An image showing the comment bar with the display name in parenthesis next to the username
    This way screen readers and mobile devices can see it no problem, and everyone has access to the display name. I double checked and there is indeed a 50 character limit on the display name field, so it's really not going to get much longer than what's seen in the picture, unless someone used 50 W's I guess. Aaand listed as username first, it leaves the display name field open to be used either as intended (with a name) or as a sort of signature quote, quip, or whatever. Should be less confusing than notifs, anyway?

    Problem: since when you edit your profile it says "Your name will be displayed on your profile and in search results" would having it display on the comment bars this way be a problem for the dw's search function?
    nometal_alchemist: (pic#2786403)

    [personal profile] nometal_alchemist 2012-03-18 01:08 am (UTC)(link)
    For my own two cents, this actually looks very nice, from the point of view of a sighted user who would really like to be able to see the "Name" associated with journals I'm replying to. In fact, I prefer this to the LJ way of doing things (the hover/mouse-over), and it has the benefit that an additional action (said hover) isn't required to view it, making it easily accessible to mobility-impaired users too.
    pne: A picture of a plush toy, halfway between a duck and a platypus, with a green body and a yellow bill and feet. (Default)

    [personal profile] pne 2012-03-21 05:27 pm (UTC)(link)
    I like that idea, too!