[dev] Gollem - Preferences for multiple files upload

[Michael M Slusarz]

[Please keep discussion on list]

Quoting Ron Cooper <rcooper at jamesconeyisland.com>:

| Quoting Michael M Slusarz <slusarz at bigworm.colorado.edu>:
|
| | Quoting Joel Vandal <jvandal at infoteck.qc.ca>:
| |
| | | Hi,
| | |
| | | Allow up to three or more files to be uploaded at once w/ Gollem is a
| | | nice idea but not all my users want this, so this patch add a
| | | preferences
| | | setting to enable/disable multiple files upload.
| |
| | Is there any reason given why they don't "want" 3 upload fields?  It
| | would be nice to have every single UI element user configurable, but
| | that would just be such an excessive overhead that it isn't feasible.
|
|
| Michael,  Why would it be an excessive overhead?  What kind of overhead
| are you referring to?  Memory? CPU? Database?  I'd really like to learn
| why.

Maintenance, memory, CPU, database.  Maintenance by the developers. 
Memory/CPU in that every time the page is loaded the variable must be
processed.  Database in that every user has another preference variable.

Once again, it is not a question of if we can make something a preference. 
The issue is that we can *NOT* make every piece of the UI user
configurable.    What if I like the action drop-down menu on the left side
of the screen?  What if I want the upload boxes to be at the bottom,
instead of the top?  What if I want a header row every 20 rows so that,
when using my 800x600 screen, the header row is always present on my screen
at a single time?  All of these are valid concerns, just as a personal
preference for # of upload boxes to display.  The problem is where does it
end?  You have to draw a line somewhere, and I have drawn that line.

The trick is to design a UI with minimal preferences that most people will
like/find easy to use.  So is the file upload patch that critical to
obtaining this goal?  In my personal opinion, no.  If there is overwhelming
support for this patch my view may change.  But for better or worse, as a
developer my voice does carry stronger weight so at this point I am not
going to commit it.

| Secondly, please adjust your screen resolution down to 800x600 to see why
| great features like this need to be in preferences.  I run at 1600x1200
| myself, so it not of any concern, but at 800x600 every inch of screen
| space becomes expensive real estate.

I run 800x600 on my laptop, which I developed this feature on.  The fact is
that practically _nothing_ is going to fit entirely on an 800x600 screen so
you are going to have to scroll down to see 3/4's of the page anyway. 
Obviously my idea of what to expect in 800x600

| | I don't see any compelling reason why this feature should be able to be
| | turned on/off (if you don't like 3 upload fields, simply alter the code
| | to not display 2).
|
| And the moment I or someone does this our code now forks or diverges from
| yours and the more its done, the more of a nightmare it is to maintain.
| And this is the primary reason why these features are very much desired
| to be added to CVS, and rightfully so, developers have to persuaded to add
| something they do not see as useful to themselves but could be to others.

All of these are valid points.  But everyone, to some extent or another, has
their personal tweaks that they add to an installation.  A personal
example: the University of Colorado uses IMP/Horde for their campuswide
webmail installation.  I work with the people that maintain it, and there
are hundreds, if not thousands, of tweaks we have done to get it working. 
Now these tweaks are all sorts of valuable to me (and the university), and
as a developer it would be all kinds of useful to commit them to the
codebase.  But 99% are of dubious value to users of IMP/Horde as a whole so
I have not committed them.  So the path runs both ways - there may be code
out there that others find useful and I find of dubious value, just as
there is code that I find extremely useful that others would find of
dubious value.

BTW, these are entirely my thoughts and the other Horde devlopers may
completely disagree, but that is the beauty/problem with a collabrative
software model.

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder