Re: [MinGW-dvlpr] SF Download Page

[Earnie <ea...@us...>]

Keith Marshall wrote:
> On Monday 24 May 2010 21:46:30 Earnie wrote:
>> Charles Wilson wrote:
>>> On 5/24/2010 8:50 AM, Earnie wrote:
>>>> I would like to spend some time rearranging the file list on
>>>> the SF page found at sourceforge.net/downloads/mingw.  As a
>>>> first step the change will focus on moving MSYS and MinGW
>>>> packages to their own top level folder.
>>>>
>>>> Any objections?
>>>
>>> I'm not sure that's a great idea. While the number of separate
>>> top-level directories is pretty large right now, it does have
>>> one advantage.  When you couple SF's presentation page's habit
>>> of sorting the top-level directories by date, this means that
>>> you can always tell what package has been most recently updated
>>> -- or tell at a glance ALL of the packages that have been
>>> updated since a given date, simply by scanning the list.
>
> Yeah, IF you are prepared to wait like forever, while that initial
> page loads to completion.  Usually, I've clicked on the File/Folder
> Name column heading, to get an alphabetically sorted view, (which I
> find to be CONSIDERABLY more useful), about half a decade before
> that ever happens.
>
>> Have you reviewed the beta for sourceforge.net/downloads/mingw?
>> That most recent stuff goes away in that view.
>
> But that isn't a view which Joe User is likely to land on readily.
> As I understand it, this view is intended as a replacement for the
> browser based File Manager, for use by package maintainers to upload
> content, rather than for users to download.
>

Actually it is a new service that SF wants to offer to those who only 
require file distribution.  So they expect non-project users to be 
looking at the list of files from that view.

>>> However, if we just have two or three...all that information is
>>> hidden inside the top-level directories.  AND, you can never get
>>> a feel for "all the packages updated since X" without peering
>>> inside each of those top-level directories separately.
>
> Nevertheless, we have had countless complaints about there being just
> too much clutter, making stuff way too difficult to find; I don't
> recall anyone saying they actually find it helpful to be able to see
> all available packages sorted in reverse chronological order of
> release, (and personally, I find the Newest Files panel to be just
> another unhelpful distraction, but it is there for those who do want
> to see what's new).  The message I'm getting, from Joe User, is that
> he has considerable difficulty selecting what he should download,
> from amongst all the noise.
>

Yes, Joe User doesn't have a clue.

>> I mean moving the directories as they exist to two top level
>> directories.  So move 'MSYS regex' to 'MSYS' and 'MSYS libxml2' to
>> 'MSYS' but leave the files of 'MSYS regex' and 'MSYS libxml2' in
>> those directories.  The most recent files will still be listed in
>> the AJAX view at the top.
>
> So, you would have:
>
>    MSYS
>      :
>      :---- libxml2
>      :
>      :---- regex
>      :
>

Yes.

> (and a similar tree rooted at MinGW).  That way, we end up with two
> (still rather long) lists, each about half the size of the one very
> long list we see at present.  That's surely better, (and within each
> list, the user would still retain the option of a chronologically
> sorted view), but I think that those two lists will still be too
> long.  I would subdivide them further, making it easier for users to
> identify, and separate, the essentials from the optional extras; if
> the names of those second tier folders are chosen for alphabetic
> sorting, with the essentials first, so much the better; (this was my
> intent with "Base System" for the essentials, and "Supplementary
> Tools" for the optional extras, at the last reorganisation, before
> SF stuffed it up again).
>

That may come later.  Making the list half as long it is now and each 
half related to MinGW or MSYS is a good step forward.  I think SF has 
gone a step toward the correct direction and at least for now is using a 
simple method toward file delivery.  But we are aware of the boggles 
along the way to get to where they are now.

>>> If users are forced to download everything manually, and aren't
>>> sure what to download to start with, then the number of
>>> different directories with no "categorization" is confusing.
>
> It could be, if the subdirectory names are not well chosen, but we
> should surely be able to choose some suitable names, which provide a
> suitable form of categorisation.
>

As long as we are consistent and can explain ourselves, any taxonomy to 
categorize would be better than a long list of files.  But we need to 
give consideration to the vocabulary to convey easily what is meant.

Earnie