code push shortly

[denise]

We'll be beginning a code push in about 15-20 minutes. Please put up your seat backs and return your tray tables to the full and upright locked position. We'll update this entry when we're done!

(2:40AM EST: As always, the prep turns out to be more involved than we predicted. We'll hopefully be starting soon.)

3:10AM EST: And, we're done! Please report any issues here or to Support.

Comments

[unicorn]

Question, if this is the place for it - is the new icon page behavior something introduced on its own merits, or is it the first of more tools to organize your iconpage? I'm not sure I like it on its own, but combined with the second I wouldn't mind it. :o

[denise]

Look for a more in-depth discussion in the next dw-news post (which should be in a day or two, good lord willin' and the crick don't rise), but the long and the short of it: we've gotten a lot of feedback from people that managing icons is very difficult when you get up into triple digits and loading icon pages is a bear when you get past a certain number of icons on the page. It's one of the most consistent things we hear when people are talking about icon management -- even if it's not brought up as the first consideration, whenever we start talking about icon limits, large numbers of icons, etc, someone will bring it up eventually, at which point there is a slew of +1s and "ooh, yeah, I hadn't thought of that".

Now, a lot of people don't run into that situation very often, because it really only starts getting painful around the 200+ icon limit and that's only premium paid and seed accounts (of whom there are about 2600 total), but since we're actively developing icon add-on packs (see brainstorming; it's what I've been coding this week) and hopefully people will be able to have as many icons as they want (and can afford) very soon, it will start to become more of a problem!

So, revamping how icons are managed (and how they display) is an ongoing project, and one we've been working on for a while. This is, indeed, the first of many more tools for storing, displaying, managing, and otherwise manipulating large numbers of icons! (Also included, and soon to be live, will be the ability to view your /icons page in your journal style, rather than the site style (and, conversely, to not do so if you don't want), which has included a shitpot (that's a technical term) of rewriting the backend code for how that page is displayed and generated; the better icon browser included as part of the new Create Entries workflow that's currently in beta testing; and, invisible to you guys, improvements in how we generate/store/manipulate icons in general, everywhere on the site.)

The code for paginating icon pages has actually been written for ages, we just didn't turn it on until now (it's a critical part of a) the "display icons in journal style" system and b) being able to have larger numbers of icons in general). We've tweaked it a bit post-push to include an explicit link to the ?view=all page so people will be able to get to the full icon list more easily if they want (that part was also already coded but we just overlooked adding the link on the /icons page, oops) but I really think people will start to appreciate it once icon add-ons go live (which should hopefully be within the next few months) and suddenly people start having like 500 icons :)

[tyger]

My last icon in my second page is overlapping the page links, if that makes sense. (On Safari 5.1.2)

[denise]

Ta, we'll see what we can do for that!

[eruthros]

I'm having a similar problem, where the last icon in the left column has a random box of colors and stripes over it. I took a look at several icon pages and it happened on all of them, but only on the last page of multiple-page sets of icons.

The random box is the celerity sidebar color plus white stripes. (Celerity, Firefox 7.0.1.)

[momchester]

Can we permanently turn off icon pagination? Like, so we don't see icon pages as being paginated ever? I can see the value of it, and why other people would want to be able to see my icons on two pages, but personally I don't want to have to click an extra link to be able to see my full icon set. Or anybody's, tbh.

[denise]

We have no plans to add in a "disable pagination" option (doing so would eliminate a lot of the benefit we get from adding it, which is both a performance and usability boost) but you can get to the full version by adding ?view=all to the end of the URL, and as soon as fu finishes fighting the code, that link will be added underneath the pagination box (we'd intended to do it before the push but it got accidentally left out!) So, you won't be able to do it by default, but you can still view the full version if you want to.

[capri]

I'm not sure if it's my iPad or the site, but I'm accessing my reading page via mobile Safari now and something weird is going on with the icons/mood themes/cut tags. My friends' icons are mixed up, an envelope with a lock on it appears in place of the little triangle next to a cut, and it was really weird for me when I realised that a mood icon on someone's post was someone else's icon.

I'll see if I can get a screencap.

ETA: I have a screencap but blurring out words to protect my friends' locked entries is more than I'm capable of on this iPad, apparently! I'll update this if it's still a problem when I have access to my laptop later.

[denise]

Hm. I'm not reproducing it locally on my laptop (and the iPad is in the bedroom with my sleeping wife, heh), but the most likely culprit is an entry posted by one of your friends with malformed HTML. Since I'm not seeing it on the public version of your reading page, try this and see if the problem persists: http://capri.dreamwidth.org/read?security=public

[sharpiefan]

Um. When I open a cut-tag by using the inline option (which I love, BTW - I don't know how I'd manage without it!), and then close the cut-tag by using the arrow at the end of the cut, I still have the /read#span-cuttag showing, which means that when I scroll up to the top of my reading page and refresh it, I end up looking at the same entry I'd previously expanded.

This was happening before the latest update, but only started happening relatively recently. And it's, frankly, annoying. (I'm running Firefox on a Windows Seven laptop... can't remember if it happened when I was still on Windows Vista 'cause I recently got a new laptop, with the new Windows.)

[ninetydegrees]

I think this has been fixed in the new JS behavior because I remember this issue but I can't reproduce it now and I have JS beta testing turned on.

(Also if an official wanna answer, this is bug 3143 :).

[with_discipline]

Thank you SO much for the icon pages. I can't remember how many times I've managed to freeze firefox completely by opening mine. I saw that overlap on the last icon page was reported, but otherwise, this is fab. Can't wait to see add ons now! :D

[articletwelve]

This is a bit of a weird one, but: I use the search box in the icon browser to sort icons before I pick them, and I use different symbols to do it (equals sign, parentheses, and brackets). The equals sign and brackets are working, but nothing happens when I just put in an open parentheses, for example. (It works if I put something inside the parentheses, but not that single "(" symbol.) It worked fine yesterday, so I'm guessing the code push had something to do with it, though I have no idea how something that specific could have broken! And yes, this does happen in both the normal and the beta icon browser.

[denise]

you're right, that is a bit of a weird one. *G*

I have no fucking clue personally, but I've poked fu to put it on her radar to see if she has any idea! (Although, having said that, I think I do have an idea about what it might be. Or at least a clue about the section of code that changed to cause the problem. Will report back.)

[fu]

Oops, fixed now, thanks for pointing that out!

[continuum]

The little alt. menu when you hover over icons in comments seems to be displaying the icon descriptions and comments, as well as just the keyword. I'm not sure if this was intentional or not, but it does look a bit overcrowded this way, especially since the coding (i.e. "user name = x") shows through.

[denise]

Deliberate, and for accessibility (there'll be a section about it in the next news post): there was information available in the alt text (for screenreaders, etc) that was not also available to non-screenreader users via the title text (the thing that your browser shows you on hover), which is bad practice for usability. (Ideally, no information should *only* be available to sighted users, or *only* be available to screenreader users, or *only* be available to keyboard users vs mouse users, etc. There's a problem in that the hover menu and the title tip information on images aren't accessible to people who can't use the mouse or who can't use cursor hover such as mobile browser users, but that's the next problem we're brainstorming on solving.)

(You also run into a problem in that the standards say that alt and title shouldn't be the same, but we worked around that by changing the order in which username/description/keyword/comment appear, moving the information more likely to be useful to visual vs screenreader use closer to the front of the text strings so the content is the same but presented in a different order. We're also not above ignoring standards when standards work against accessibility rather than for it; accessibility for people with disabilities of all types -- not just "screen reader users", which is what many sites mean when they talk about accessible design -- is one of our key principles and it drives many of our decisions, if not most of them, in some shape or form.)

Also, by showing icon descriptions if they exist (see the title text on my icon for instance; its 'description' is the bit in parentheses) our hope is that it will make more people aware that descriptions exist, and encourage them to fill them out if they haven't already. The description is what's read to screenreader users (and shown to people using text-only browsers) for them to know what the icon consists of, since so many people use icons as an additional channel of metadata about the comment and that informational channel is lost to non-visual access. Many people have filled out the description fields of their icons (I've managed to describe all the ones on this account and about 3/4ths of the ones on my pesonal account! finally) but many more haven't, and we're hoping that by showing people (a bit of) what screenreader users experience when they use an icon, it will help them realize why it's important to add those descriptions.

People weren't using the description field to describe their icons because they never saw those descriptions and it's hard for someone who's never seen/used a screenreader to know how it presents information! (I have a friend who's blind and once I asked her if she'd mind demonstrating how she interacts with the internet. It was stunning. The screenreader reads at like 4x a 'normal' human speed and she can tell what she's hearing within fractions of a second to skip ahead if she's not interested in that section. The end result sounds like Mickey Mouse on helium with a horrible habit of cutting himself off one syllable into every word, and yet she understands it perfectly. It's kind of amazing.) So, by showing the description field, people can know what it is that screenreader users are hearing.

We wavered back and forth over whether to include the comment field, especially since in practice it's mostly used as a dumping ground for "notes about the icon geared towards display on the /icons page" instead of being information that's most useful at the time of viewing; I'm still not 100% convinced that the comment field has to be there. (We've been dithering about it for over a year and a half, actually; the discussion started up 2010-07-13 and continued on and off until earlier this month when we finally threw up our hands and said fuck it, we'll make a decision even if it's not the version that ends up sticking around.) But the description, yeah, we think exposing that is an important part of our accesibility commitment, because it will hopefully keep that information from being hidden away in alt text and keep people from not even realizing that the description field exists.

(Every browser handles alt text slightly differently, but none of the Big Ones ever use it for the hover-over tooltip; they all use the title attribute for that. It's very, very annoying, and a real mistake from an accessibility standpoint, because it means that visually-oriented users have no idea what alt text is or does or should be used for in most cases.)

[wehappyfew]

I love the new icon pages. *_* It's so awesome. But did you guys intentionally set it up so icon keywords/descriptions/comments show up in e-mails? And if so, can I ask why? It threw me for a bit of a loop and I kinda feel like it makes them feel a little... cluttered, I guess, since we've got the comm/journal names in there, too. (Which I love, btw.)

[deborah]

yes, this was intentional as well. Alternative text wasn't showing up in e-mails, so sighted users could see what icons were being used, but screenreader and plaintext e-mail users had no idea what icon had been chosen. It was another accessibility thing -- how do you make information available to screenreader users which is already available to sighted users.

[matgb]

Has somethign been done that might affect some S2 layouts? miss_s_b's midly customised layout is borked for some readers, but isn't browser dependent, not had time to look into it properly but it's very strange.

It must be linked to a change but I don't see what it could be and my brain's not working properly (I did her layout ages back and the notes are ont he dead netbook)

[ninetydegrees]

Since she's using Modular, I'm pretty sure this is related to this change. It seems to mess with the padding in #header. Hmm. *off to play with Web Dev*

[blue_rampion]

I do have a question, if it's alright to ask here - would it be possible to have a way to both view all icons and have them sorted in keyword order? At the moment, the view all option will only show my icons in upload order.

[exor674]

As a workaround, you can visit http://username.dreamwidth.org/icons?sortorder=keyword&view=all

[toxicspiderman]

With the new hover menu -- I read all the bit above about accessibility, and agree -- but it's showing all the keywords associated with an icon, rather than the ones I used. Which I don't feel is right -- if I picked a certain keyword, I want that to show, because it's what I meant to use.

Granted, this is me speaking as an RPer, who often adds new keywords before actually making the icon if I'm posting from my phone or something. Or if I have an expression on a character's face that can be taken a number of ways, and have specifically keyworded each of them. Or, for that matter, if I've had an account's paid-status lapse and combined keywords so that old threads are at least vaguely correct in expression, and hovering will tell me what icon I did use.

I would vote against the comments, because almost all of mine are either credits (which are less useful when the usernames aren't clickable) or hyperlinks (when crediting takes more space than a comment box, and I'm just redirecting to a journal entry with explanations.

(And yes, I need to go write in descriptions, I just haven't gotten around to it. Alas.)

[azurelunatic]

I am another person who will use the same icon, but selected by different keywords, for different purposes.

[Edit: ... hmm, it looks like this icon isn't currently title-texting the other keywords I know it has...]

[narrativian]

Works for meeee!

Really, I'm only writing in to tell you that you and Mark are AWESOME and I've stopped renewing LJ and have given you my money instead and will carry on doing so :D

[juniperphoenix]

The location of the userhead icon has changed (from http://s.dreamwidth.org/img/silk/identity/user.png to http://www.dreamwidth.org/img/silk/identity/user.png), so userheads aren't displaying correctly in old posts where I used the full linking method to refer to a user. I'm not positive this started with the code push, but I didn't notice it until yesterday.

[justice]

Hello. Is there a way to make it so that the "view all" is right up next to the icon order, so that we can get to it right away? My screen for my smart phone is very small, so having to scroll down whenever I want to find an icon and then load another page is going to be tedious. I understand if you can't for aesthetic reasons, but it's a thought.

On that same thought, being able to do keyword order + view all without having to manually type it in would be nice for the same mobile reasons.

Furthermore, I was wondering why the Name Field is rejected but this extensive description is now okay? I understand and am 100% behind the accessibility of having the description there, but I would love to have a name available instead of a username. Someone else mentioned it on this page. Should another dw_suggestion post be made?

Also, I'm personally behind not including the comment field in the hover, because it feels like it will just be complicated all around. Aesthetically and otherwise.

[denise]

The "extensive description" was always planned to be in the title text -- the question of what should be in the title text from an accessibility standpoint was first discussed two years ago and we've always intended to put the description in. So, the question was never "display name or description", it was "display name in addition to description".

This is an accessibility issue, not an aesthetics issue, and accessibility trumps pretty much everything, so we aren't likely to change out display name for username (especially since with most non-RP use cases, the display name is something that has no relation to the account and it doesn't make any sense to have it as part of the alt or title). However! This change actually does nearly everything you want having the display name in the title text would do: if you'd like the same effect, you can write your icon descriptions to have the character name in them, which not only works to get the character name into the tooltip, it also helps tell screenreader users who the icon is of.

[white_mage]

I have a friend trying to create a journal and it keeps saying she's entering the info too fast? I tried to do it for her and it told me the same thing. Are invite codes required again?

[denise]

Probably a side effect of switching to a different captcha provider. Looking into it!

fastly.net

[somnolentblue]

Hi! dreamwidth asked re: oddnesses on DW. I suddenly don't have cut tags on my journals on any of my various browsers: Firefox (mac), Safari (mac), Firefox (Win7), AtomicLite (iPod), or Safari (iPod).

Also, NoScript on the mac and netbook are asking about scripts from fastly.net. I went ahead and allowed them on the Mac, but that doesn't do anything about the cut tags.

(I wasn't entirely sure where to drop a comment, since my twitter is locked and there's not a new dw_maintenance post; I could also comment officially in support.)

Re: fastly.net

[denise]

This is fixed now. Sorry about the hassle!