LJ: why the new update page is bad

I just submitted the following support request:

(Yes, I saw the note that you're working on problems here, but I'm interpreting that as "doesn't work in some browsers", or last night's date bug, not "difficult UI".)

While it is not as bad as it was last night, the "update journal" page is still too wide to be usable without lots of horizontal scrolling. The hard-coded width of 760 pixels in the content pane (this excludes the sidebar links in the classic style) seems to be the core of the problem. I assume you chose 760 to be under 800, and that you're assuming users will maximize the browser window if need be, but it's a bad idea to hard-code assumptions about a user's environment. It would be better to use proportions and let the browser handle the rendering.

---

I didn't say this in the support request, but they should think more about how they roll out changes like this. When you change existing functionality you're bound to break something, because you can't think of every combination of browser, usage pattern, special input needs, etc etc etc. In the case of the web site, it would have been really, really easy to provide a "having trouble?" link that went to the old, working form.

Followup: I received the following reply. Doing this solves the scrolling problem; some other aspects of the display are then screwed up (overlapping input areas), but they seem to know about that already.

"Thank you for your report. However, there is no way to view the Update Journal page in the old style. Viewing this page in the new LiveJournal style, http://www.livejournal.com/update.bml?usescheme=xcolibur may solve the screen-stretching problem. I apologize for the inconvenience, but please be assured that developers are working to find a resolution."

grocery-store interface question

Today, as I approached the checkout lines with a dozen bagels, my salad, and a few other things, I found myself wondering about the specification of "12 items or fewer". (Fewer! They actually said "fewer" instead of "less"!) I assume they do not mean 12 individual items no matter how packaged, else you could never go through with a case of pop or a bag of potato chips. So do they mean 12 scannable things, or 12 items at the smallest unit size sold? Would my dozen bagels be ok in a pre-packaged bag with a UPC symbol but not if the clerk had to type in "12 @ [price]"? Or is the fact that it generates a single line on the receipt what matters?

These thoughts brought to you by "total items: 20" on my receipt, a need to maintain my reputation as a pedant, a desire to test posting by email, and caffeine deficiency. :-)

grocery-store interface question

[I posted this and then edited it, and the edit attempt failed with just "error" and the post disappeared. Maybe it's really gone; maybe it's not.]

Today, as I approached the checkout lines with a dozen bagels, my salad, and a few other things, I found myself wondering about the specification of "12 items or fewer". (Fewer! They actually said "fewer" instead of "less"!) I assume they do not mean 12 individual items no matter how packaged, else you could never go through with a case of pop or a bag of potato chips. So do they mean 12 scannable things, or 12 items at the smallest unit size sold? Would my dozen bagels be ok in a pre-packaged bag with a UPC symbol but not if the clerk had to type in "12 @ [price]"? Or is the fact that it generates a single line on the receipt what matters?

These thoughts brought to you by "total items: 20" on my receipt, a need to maintain my reputation as a pedant, a desire to test posting by email, and caffeine deficiency. :-)