Technology requirements in browsers

[Benton, Kevin]

> > Unfortunately the devil is in the details (what's "basic"?), and
> > supporting even basic functionality in these browsers is a lot more
> > work and code complexity, which represents a significant opportunity
> > cost. The time and energy we spend supporting them we can't spend
> > making things even better for the vast majority of our users.
> >
> > I suggest we drop the requirement to support these browsers but
allow
> > developers to continue to implement such support if they want it or
> > have users who want it. This way we place the onus for supporting
> > these browsers on the folks for whom they matter instead of making
> > everyone pay the tax for this tiny minority of users.
> 
> I won't presume to tell developers how to spend their time, but please
> make it clear in the relnotes when you drop support for Lynx so I can
> look for another bug tracking product.
> 
> The ability to search & edit bugs, download or upload files, etc.
> directly from a Unix system where development or testing is taking
place
> is simply too useful to discard.

Hi Damien.

I'm certainly not suggesting that we abandon the basic support we've
always had to allow users to enter new bugs and handle basic bug updates
via an interface that works in basic HTML.  On the other hand, I don't
think it's fair to ask us to tie one hand behind our backs while writing
more advanced features in Bugzilla because we're going to keep someone
from being able to use them in lynx.  You can still ride horses as a
method to get to/from work, but that doesn't mean that it should prevent
me from driving my car, does it?  As a society, we made a decision that
it's safer for people to stay off high-speed highways if they're on
foot, bicycle, horseback, etc. because the speed differentials are
incompatible for safety's sake.

At some point, I think it's fair to say that this community is going to
make a decision to start using some of the more advanced tools available
to us for providing information back to users.  Unfortunately, some of
that stuff is not compatible with browsers like lynx.  Creating user
interfaces that provide the best experience for the greatest percentage
of users we serve is (I think) our biggest concern.  No matter how
functional our software is, if it doesn't work in a way that the
majority (of users) appreciates and understands, they won't use it.

My boss's boss said something to a group of us a few days ago that made
a bunch of sense.  "Leading isn't leading if nobody is following you.
If nobody is following you, you're just out for a walk in the park."  We
can't lead if nobody is following us.  I think there is a very large
segment of the potential user community that doesn't use Bugzilla
because we aren't using more pull down menus, user-side input
validation, etc.

Regardless of what we do with the user interface, it'll remain very
important for us to continue to provide a reliable and stable API that
works with other software.  It seems to me that a WAP-like interface
into Bugzilla (on top of our API) makes sense at some point.  I think
that kind of interface might work well with lynx also.  Maybe you'd like
to help us develop that part of Bugzilla?

---
Kevin Benton
Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator
Personal Computing Systems Group
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.