Issue 122233 - sourceforge.net: download file name column of directory too narrow
Summary: sourceforge.net: download file name column of directory too narrow
Status: REOPENED
Alias: None
Product: Infrastructure
Classification: Infrastructure
Component: Downloads (show other issues)
Version: current
Hardware: All All
: P3 Minor (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL: http://sourceforge.net/projects/openo...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-05 06:48 UTC by Rainer Bielefeld
Modified: 2015-11-09 19:08 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Screenshot (303.08 KB, image/png)
2013-05-05 06:48 UTC, Rainer Bielefeld
no flags Details
Also problems in info dialog (244.36 KB, application/vnd.oasis.opendocument.graphics)
2013-08-07 05:05 UTC, Rainer Bielefeld
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2013-05-05 06:48:47 UTC
Created attachment 80641 [details]
Screenshot

The styling of the directory is very inexpedient:
a) half of the screen width is wasted for empty grey areas at the left and the
   right
b) advertisement (Latest tech jobs) has more column width than file names

this might not affect most normal users, but for QA staff finding the required file is a pain.
Yes, that's a general Sourcforge website problem (and a fad on many other websites), but the AOO project should have some influence there. And if they do not see a possibility to offer a useful design AOO should find a better solution.
Comment 1 Marcus 2013-08-05 13:49:48 UTC
@Rainer:
This is not fixable from the Apache side. Please contact Roberto from Sourceforge.net at the dev@ malining list. Thanks.
Comment 2 Rainer Bielefeld 2013-08-05 14:51:31 UTC
@Marcus:
Thank you for feedback. 

Unfortunately I will not do that "contact Roberto", that's not my turf. I report bugs "Somehow related to AOO" in Bugzilla, and that's the only discussion platform I will use, except I explicitly have agreed. I am not involved anywhere in Apache organization (although i am rather busy in Bugzilla), and (like most other "only users") I will not subscribe  additional lists, search around for mail addresses or similar.

It's discouraging for users to get advice like Comment 1 from someone@apache.org. If you know who can help, why don't you contact Roberto? I don't know him. 

It's like in a restaurant, I am not interested in details how the workflow in the restaurant is organized an at what waiter's table I sit, I don't want to get waiter Roberto's phone number to ask him why he is not at work today, I simply want to order my steak within acceptable time. 

And because I see evidence that from time to time someone will wait for a waiter in vain in AOO Bugzilla I submitted "Bug 122803 - Make sure that developers read Bug reports related to their field of activity"
Comment 3 Rainer Bielefeld 2013-08-05 15:15:16 UTC
And by the way, if AOO uses a download platform with file name columns too narrow for the file names, someone might want to think about shorter filenames ("Apache OpenOffice" already is the heading of the page, may be "AOO_4.0.0...would be sufficient?) or filenames showing the distinguishing part at the beginning of the name, or, or, or.
Comment 4 Marcus 2013-08-05 15:42:39 UTC
I've mentioned it as I thought you know Roberto already. That was the reason for the short hint. OK, it doesn't seem so. BTW: No need to write half a book of comments. ;-)

The filenames in release files are a new topic.

I'll set Roberto as assignee. Let's see if he can help.
Comment 5 Marcus 2013-08-05 15:43:45 UTC
@Roberto:
Please can you take over this issue? Thanks.
Comment 6 sebb 2013-08-05 19:20:21 UTC
There's a related issue - some of the file sizes are wrong as well.

For example, Apache_OpenOffice_4.0.0_Win_x86_install_en-GB.exe shows as 129 MB (136,201,626 bytes) on Windows XP. 

However on the SF download page e.g. [1] it shows as 136.2 MB.
Looks as though the size was divided by 1000 rather than the usual 1024.

[1] http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-GB/
Comment 7 Roberto Galoppini 2013-08-06 19:54:59 UTC
Those are two separate issues actually.

Issue #1 (opened by @rainer )

When logged in there are no no ads and there is plenty of room.  When not (with ads), the Ad reduces the canvas by about 1/3, which is only enough room to display about half of the particularly long filenames.  In that instance, no amount of tinkering with other column widths will free up enough space to make the full name visible.

What we might do quickly is a mouse-over effect, so that when the mouse rolls over the filename, the UI expands it in some way to reveal the full name. 

Would that work for you?


Issue #2 (opened by @sebb )

Thanks for heads up on that, it's scheduled for the next sprint, check it out at SourceForge ticket system: https://sourceforge.net/p/allura/tickets/6524/
Comment 8 Rainer Bielefeld 2013-08-06 20:30:48 UTC
> What we might do quickly is a mouse-over effect, so that when the mouse
> rolls over the filename, the UI expands it in some way to reveal the full
> name. 

@Roberto Galoppini:
Thank you for feedback! I am not sure whether I understand your suggestion. Are we talking about some kind of tooltipp (it seems that changed since I submitted this report)? I'm afraid that will not help very much. To decide what will be required a human being will want to see the complete list with all relevant info, not to read the file names one by one with mouseover. 

But of course a clear, simple, readable tooltip can be an improvement, at least with my Seamonkey the result I saw yesterday was much worse than that what I see today.
Comment 9 Roberto Galoppini 2013-08-06 21:08:04 UTC
Yea, a tooltip like kind of thing. Think we could do that really quickly, while redesigning the whole page would probably take some time.

Did you try to log-in as SourceForge user by any chance?
Comment 10 sebb 2013-08-06 22:21:23 UTC
(In reply to Rainer Bielefeld from comment #8)
> > What we might do quickly is a mouse-over effect, so that when the mouse
> > rolls over the filename, the UI expands it in some way to reveal the full
> > name. 
> 
> @Roberto Galoppini:
> Thank you for feedback! I am not sure whether I understand your suggestion.
> Are we talking about some kind of tooltipp (it seems that changed since I
> submitted this report)? I'm afraid that will not help very much. To decide
> what will be required a human being will want to see the complete list with
> all relevant info, not to read the file names one by one with mouseover. 

I agree. 

The tooltip is only marginally useful - the same info was previously available by clicking on the (I) button, although that also suffers from lack of space for the full file name, which wraps. And in Firefox at least, the full URL appears at the bottom of the page when hovering over the link.

However neither is particularly convenient when looking for the correct file to download.

Just discovered that the full file name is shown in Chrome and Opera if Javascript is turned off. So clearly it's possible.
Comment 11 Rainer Bielefeld 2013-08-07 05:05:19 UTC
Created attachment 81259 [details]
Also problems in info dialog

Currently also the source forge "Info" field has problems with the long AOO file names (screenshots from Seamonkey browser)

But to say it clearly, I want to retain relevent info in the file names, I dislike solutions like "jxpiinstall7.exe" where you never know what version exactly will be installed.
Comment 12 Andrea Pescetti 2013-08-08 11:37:05 UTC
I confirm that file names in
http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/it/
are cut, but I don't see this issue as much relevant: final users are not supposed to use those links, and those very few people who really need an FTP-like access can use the Apache mirrors: I think the work is still ongoing (you only see checksums at the moment), but Infra is going to provide a fallback at http://archive.apache.org/dist/openoffice/4.0.0/binaries/ or http://www.apache.org/mirrors/ooo.html (ask the dev list if you need more information about this).

Roberto: I tried your suggestion to log in at SourceForge; if I open
http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/it/
indeed the ads disappear, but the "Latest Tech Jobs" box is still shown (in my case) and it is still in the way, so logging in does not completely solve the problem, unless I'm missing some options in the profile configuration.
Comment 13 Roberto Galoppini 2013-08-20 18:54:59 UTC
If you're a project admin and you're logged in file names are not cut. If this is something only AOO folks would need to double check files I believe we could address the issue by having them as project admins.

Does it make sense?
Comment 14 Marcus 2013-08-21 18:19:10 UTC
@Roberto: I doubt that this will help as the normal user has not the special view like the admins. If we want to position this webpage as a kind of last resort for the user to choose their favorite build (when every download scripting fails), then everybody should be able to read the complete filenames. And at the moment IMHO it is indeed better than the Apache mirror system.
Comment 15 Roberto Galoppini 2013-08-22 05:19:41 UTC
@Marcus I see Andrea has a different take on the subject, in his opinion that is not a resource aimed at end-users. Maybe we can discuss this further on the dev mailing-list?

Note that also Rainer's initial comment seems to be aimed at QA people.
Comment 16 Marcus 2013-08-22 18:53:31 UTC
@Roberto: Sure, feel free to bring it back to the dev@ mailing list.
Comment 17 Andrea Pescetti 2013-08-25 18:38:18 UTC
Feel free to take this to the dev list again, but in short...

1) I don't see this as relevant to final users: they will never navigate the SourceForge directory

2) Volunteers (and whoever wants to browse directories) can use our (Apache's) infrastructure, that now has exactly the same files, plus checksums, and displays full names: for example, see http://www.eu.apache.org/dist/openoffice/4.0.0/binaries/

Unless I'm missing some use cases, I'd say we can live with it.
Comment 18 Roberto Galoppini 2013-08-26 12:01:58 UTC
Thanks @Andrea for the further clarifications. It seems to me all the people interested in the subject are following this issue, I'll wait +72 hrs and lazy-consensus-wise I'll close the ticket if none objects.
Comment 19 Roberto Galoppini 2013-09-12 09:52:08 UTC
As per my previous message I'm closing the ticket because it's not relevant to en-users - as per @Andrea feedback, and AOO volunteers as admins of the AOO mirror at SourceForge can get access to those pages with no displayed ads.

If you need to be an admin of the AOO mirror feel free to contact me or other admins (e.g. @Marcus).
Comment 20 Rainer Bielefeld 2014-03-20 19:00:14 UTC
If you think those downloads are not for normal final users, drop all that statistics fripperies and show a normal list like <ftp://ftp.rz.tu-bs.de/pub/mirror/openoffice-archive/localized/de/3.2.0/> or so. 

<http://www.eu.apache.org/dist/openoffice/> is not an alternative if you are searching for older versions.

Please excuse me for the rude comment, but the current solution is a horrible mess.
Comment 21 Marcus 2014-03-21 19:51:21 UTC
@Rainer:
If you want to get older release, please go to our starting webpage for archived builds:

http://www.openoffice.org/download/archive.html

It is not intended that end-users start at Sorceforge.

Therefore I think it's OK to leave it as it is.
Comment 22 Rainer Bielefeld 2014-03-22 08:58:50 UTC
Hi Marcus:
I know that mirror here in my hometown, during OOo@sun I was involved (a little) in keeping it running.

End-user argument: Of course I know the trick with "Styles = none" in browser, and may be not too many users get astray to there. It's a matter of pride.
Comment 23 Marcus 2014-03-23 16:16:43 UTC
@Rainer: We at AOO cannot change this. Please get in contact with Roberto from Soureforge. He is the only one who (may) can help you.
Comment 24 Marcus 2015-11-05 22:15:35 UTC
As with comment #23 this is no issue of Apache OpenOffice but SourceForge. So, it has to be fixed there. Closing this issue.
Comment 25 orcmid 2015-11-05 23:54:24 UTC
I am dissatisfied with the way this conversation went, especially with regard to folks who are by no means typical end-users claiming what end-users might or might not do.

We already had an example of a QA person (probably a power user) needing to see the details.  

Also, kicking the can to SourceForge is strange.  It is about how a service for us works for *our* users, not typical SourceForge users.  (And so being logged in is a strange condition.)

I think this should remain open until we have the people who claim it is important to improve are fully heard.  I just don't think it makes sense to tell end-users that they need to negotiate with SourceForge themselves.

And Roberto, as a member of the AOO PMC is a great candidate to carry the word to SourceForge, as he has done here.  I don't want to minimize that and that he offered something that could be done immediately to improve the situation.  

The issue about ad placement is a companion concern and needs its own consideration.
Comment 26 Marcus 2015-11-07 12:33:19 UTC
(In reply to orcmid from comment #25)
> I am dissatisfied with the way this conversation went, especially with
> regard to folks who are by no means typical end-users claiming what
> end-users might or might not do.
> 
> We already had an example of a QA person (probably a power user) needing to
> see the details.  

This is more than 1 year old and there is no further discussion. Also there are no further interested people on the CC list - besides the usual listeners. ;-)

> Also, kicking the can to SourceForge is strange.  It is about how a service
> for us works for *our* users, not typical SourceForge users.  (And so being
> logged in is a strange condition.)

I find it strange that you want to draw a special relation here.

SourceForge is no service for or from Apache or OpenOffice. We are using its great service and they serve it to many, many others, too.

When other projects on SourceForge also use long file names like we do, then they would see the same problem. I haven't looked around but, again, it's no special problem that belongs to OpenOffice alone.

> I think this should remain open until we have the people who claim it is
> important to improve are fully heard.  I just don't think it makes sense to
> tell end-users that they need to negotiate with SourceForge themselves.

Why should a issue stay open that has no attention and no further comments?

And end-users do not need to search on SourceForge. For this we have our own download webpage.

> And Roberto, as a member of the AOO PMC is a great candidate to carry the
> word to SourceForge, as he has done here.  I don't want to minimize that and
> that he offered something that could be done immediately to improve the
> situation.  

Right, Roberto is the right one to try to change it. AFAIK he knows the issue but there is no solution until today. So, maybe it's not technically possible without to change much more on their webpage.

@orcmid:
Sorry, but I don't think that this issue is right placed in the issue tracker of OpenOffice due to the reasons I stated above. But to do something constructive I will notify Roberto (again) about the problem reported in this issue.
Comment 27 mroe 2015-11-07 16:29:26 UTC
I'm using Firefox with NoScript AddOn. I see the complete filenames. But the reason is that all scripts are disabled. If I allow the execution of scripts from fsdn.com the table will formatted, so that the filenames are cropped.
Comment 28 orcmid 2015-11-07 16:50:18 UTC
(In reply to Marcus from comment #26)

> @orcmid:
> Sorry, but I don't think that this issue is right placed in the issue
> tracker of OpenOffice due to the reasons I stated above. But to do something
> constructive I will notify Roberto (again) about the problem reported in
> this issue.

Thank you Marcus.  I see you doing that on the dev@ list.
Comment 29 orcmid 2015-11-07 16:55:20 UTC
(In reply to Marcus from comment #26)

> This is more than 1 year old and there is no further discussion. Also there
> are no further interested people on the CC list - besides the usual
> listeners. ;-)

For me, this kind of silence on an obvious usability issue is something to taken as an indication that someone gave up on us. The issue did not disappear.  Confidence in the project to take users seriously may have disappeared.

The problem is we don't often get to know.  I don't think we are taking the fact that users took something seriously enough to figure out how to submit a buzilla issue, and then go away a short time later, is probably not a good sign.   These are the only indicators that we have that maybe others take themselves away without saying anything, not seeing it as their job, or for whatever other reasons they might have.
Comment 30 mroe 2015-11-09 11:08:12 UTC
Sorry for comment 27. It isn't helpful.
But without a suggestion how a solution could look, I can't see what sourceforge should do.

Maybe the script implements a switch that toggles the columns "Modified" and "Size" on/off. But this will work also only for a limited length of filenames.

Maybe the filenames will separated by cutting in the middle:
Apache_OpenOffice_....tar.gz doesn't make it better ...

I think the problem is the filename itself. If one download more than one file (version/language/...) one has the same problem with different file managers.
(see comment 3)

What about
AOO_Lin64_deb_en-GB_inst_4.2.1.tar.gz
AOO_Lin32_rpm_en-GB_inst_4.2.1.tar.gz
AOO_Mac64_en-GB_inst_4.2.1.dmg
AOO_Win32_en-GB_inst_4.2.1.exe
(for future: AOO_Win64_en-GB_inst_4.2.1.exe)
and
AOO_Lin64_deb_en-GB_lang_4.2.1.tar.gz
AOO_Lin32_rpm_en-GB_lang_4.2.1.tar.gz
AOO_Mac64_en-GB_lang_4.2.1.dmg
AOO_Win32_en-GB_lang_4.2.1.exe
(for future: AOO_Win64_en-GB_lang_4.2.1.exe)
?


If these filenames truncated as now, the important information will stay visible.
Comment 31 Marcus 2015-11-09 19:08:25 UTC
(In reply to mroe from comment #30)
> I think the problem is the filename itself. If one download more than one
> file (version/language/...) one has the same problem with different file
> managers.
> (see comment 3)
> 
> What about
> [...]
> ?

I know the file names are long but when we change the structure again then we have a total mess in the download scripting with much more exceptions that needs to be checked and deopending on the results different code parts have to be executed. So, please not. ;-)

And it won't help for other projects on SourceForge.

The problem (at least what I can see) is the "Recommended Projects" box on the right hand side. If this could be re-positioned, then the filenames have the full space that is needed.

I've checked this with Firebug in Firefox. When deleting the box and disabling the fixed width for the files, then it's perfect.