Ban unresizable popups
I don’t know what makes some Web designers think they have the right to prevent me from resizing the windows on my computer screen. If designers think they can predict the exact width and height in pixels of their content in any browser, on any operating system, in any font and in any text size, they’re being incredibly naive.
For example, Rockymountainnews.com is shooting itself in the foot with its “desktop headlines” feature, which in Mozilla is sized too small for any content to be visible:
I gather the feature — which I don’t exactly understand the point of anyway — is supposed to look like this screenshot from Internet Explorer:
I’m not sure why the site’s obviously non-cross-browser JavaScript opens the popup to different sizes in the two browsers, but since the popup window has scrollbars and resizing disabled, it is completely useless in Mozilla.
It’s bad enough — but somewhat understandable — that the default sizes for many popup windows are set for what works in Internet Explorer on the PC. It is neither understandable nor forgivable for a site to prevent me from overriding that size.
In search of the Renaissance Web person
Several weeks ago, Adrian Holovaty observed to me that the staffs of news Web sites are clearly divided into developers and editors. The developers, Adrian said, focus on site improvements while the editors focus on putting up new content.
I certainly agree in a positive sense — everywhere I’ve interned and worked there has been that clear division of labor. But the more and more I think about that comment, the more I disagree normatively. Rather than isolating editors and developers on different branches of an organizational chart, news sites should make every effort to bring them together collaboratively and to build technical and journalistic skills in every staff member.
I aspire to be one of those “Renaissance Web people” who have good news judgment and headline writing skills but who are also decent programmers and interface designers. So probably part of this is personal; I just wish I knew more people with those kinds of combined talents. But even if few people enjoy overlapping the way I do, news sites would benefit simply from better communication between the two groups. Generalizing from the sites where I’ve worked, here are some problems that happen when the editorial and development teams don’t collaborate enough:
- Developers, who take responsibility for overall site design and “functions” like searching or e-mailing stories, rarely ask for input from editors, who have the unique perspective of using the site the most and thinking of things that ought to be improved.
- Editors are generally the ones answering user e-mails pointing out usability problems that only the developers can solve.
- The two groups work on different timetables, and editors too rarely ask developers to drop a long-term project for an little bit and build something interactive to enhance a breaking news story — which developers might be flattered and excited to do.
- Editors don’t have enough time or insight to discover ways to speed their workflow, something the developers could do if they knew more about the day-to-day jobs.
- Developers get annoyed when editors make “obvious” technical errors, and editors get annoyed when developers make “obvious” journalistic errors.
- Each team underestimates how busy the other is.
But by far the biggest problem is this: Separating editors and developers leads them to work on completely separate areas of the site. Editors handle front pages and article pages, while developers build database projects and automated feeds like movie listings or events calendars. After a while the journalist may give up caring about the misspelling the developer made on a page the journalist can’t modify, and the developer may give up fixing the bloated, invalid HTML the journalist creates anew each day.
News sites ought to bridge this gap, increasing communication between the two groups and getting more people comfortable in both worlds. All they have to lose are the limitations of each group’s expertise.
Agreed. I'm a function-over-form-kind-of-guy. Resizable frames are just the beginning. Absolute positioning, layouts that don't respond well to browser font settings other than 'medium', or don't respond at all to browser font settings, etc all pollute content ubiqity. I tend to think that it is a side effect of designers who learned how to design brochures before they built web sites. I know the pretty sites are, well, pretty and all, but I believe that most work to control the esthetics is just another way of restricting the use and flow of information, and that such controls are counter to the principles that have made the net so successful. Take Flash for example. Yes, people could ( and unfortunately do ) create entire web sites with flash, but where would the net be if we had started that way? What if the HTTP had been a much more complicated protocol, or even a binary only protocol? Simple is good. Device/Display independance is good. And open is even better.
Whoa, I'm getting way offtopic. You must've hit a sore spot.
Anyway, maybe it really depends on who the audience is. Many sites no longer compete in terms of content ( because they're all carrying the same stories ), they compete in terms of esthetics/user experience. Maybe Mozilla users aren't their target market. ;-( I'm using Mozilla 1.2.1 right now, but I probably don't go a week without using lynx, which almost nobody cares to check their sites against ( all I ask is for an appropriate use of alt tags ), but such is life, huh?
Ummm, in summary, I agree completely, but I apparantly couldn't say so with less than 50 words.
Followup to my own previous reply. What makes designs like the one you mentioned so offensive is that they violate one of the key principles which are believed to be key to the net's success. If you believe that the net has been so successful because it embodies these principles:
1. Nobody owns it.
2. Everybody can use it.
3. Anybody can improve it.
then non-cross-browser designs violate principle #2. If you think the answer is to use flash or shockwave, then you violate principle 3, and to a lesser extent, principle 1.