Biff said:
Actually, I don't blame the programmers.
Sure you can!
They only do what they're directed to do. It's the "committees"
of middle managers that screw everything up! And they're the
ones that give final approval.
I know nothing about how MS programming teams work -- and the MSCN
programming team, in particular. But even in a "chief programmer"
team, the external interface and the high-level logic are determined by
a programmer -- perhaps one with a lot more experience than the grunt
who does the coding. In any case, at some point in time, a programmer
is responsible for the line-by-line coding, and hopefully other
programmers are responsible for "inspecting" the results -- reviewing,
critiquing and specifying improvements. In any modern programming
environment, the finished product is almost always the result of a team
of programmers, if not an individual, who do have input on details of
the external design. In fact, often the "middle manager" has very
little involvement in the details. He/she is only responsible for
staffing and scheduling. More to the point, the real problem is: the
finished product is not used by the "middle managers" and the marketing
types who might specify the external functional requirements (usually
at a very high level, if at all). Sometimes, they rely on user
feedback (sometimes "focus groups") to evaluate prototypes and final
results. But that is only as good as the feedback mechanism and the
willingness of management to pay attention to comments. And for minor
"services" such as MSCN, I would be surprised if they even subject the
external design to users for feedback.
I have tried in vain to offer feedback on recent apparently purposeful
changes to the MSCN user interface. I have not yet found a mechanism
that gets past the first-level support person, who truly knows little
about what is going on. Of course, the MSCN UI was never very good.
But two recent changes are particularly irksome.
1. When I double-click an article title (subject line), that used to
open a new window that contained the initial article and all
follow-ups. The window had vertical and horizontal scroll bars. This
was very useful to me because on another computer with an odd pixel
dimension to make it "user friendly" for someone with poor eyesight,
this new window was the only way that I could see the entire line of
most articles. (Of course, that is because of another flaw in the MSCN
UI, which fails to have a horizontal scroll bar normally.) But that
new-window UI changed recently to include a "tree" frame on the left;
at the same time, the horizontal scroll bar was removed. Klunk!
(To make matters worse, if I try to move the right margin of the tree
frame to the left, IE freezes up. Double-klunk!)
2. I experience an odd delay (extremely long!) or failure to see the
article list when I click on the newsgroup name on the left-hand frame.
Sometimes the article list never appears; sometimes it appears only
after I click on the newsgroup name again (and again, as needed).
Looking at TCP/IP traces, I can see that the problem is __not__ with
making the TCP connection; the 3-way handshake completes almost
immediately. I suspect that this problem results from a failure when
handing off the TCP connection to another computer in the MSCN backend
network. But that is only a WAG. Arguably, it would be a routing
problem within my ISP's backend network -- but only after the TCP
connection is established. (Surprise!)
If anyone has experienced with those problems and knows of a
work-around __other_than__ using some other method of accessing the
newsgroups, I would appreciate it if you could share the information
here or send me email. Normally, I avoid the MSCN UI. But I believe I
"must" go to MSCN occassionally because some articles that I can see
using the MSCN UI do not appear in my usual web-based news server,
groups.google. (Yeah, I know: another lousy UI.)
