search

owncloud / core

:cloud: ownCloud web server core (Files, DAV, etc.)
https://owncloud.com
GNU Affero General Public License v3.0
8.36k stars 2.06k forks source link

Support directory size for directories >1000MB #633

Closed andredasilvapinto closed 11 years ago

andredasilvapinto commented 11 years ago

Can you change the web interface so it shows the actual size of directories with more than 1000 MB?

Right now it just says '>1000' for these cases, but it would be nice if you could give the rounded size (e.g.: 8796 MB -> 8.8 GB). By placing the mouse over the number it could show the real size in MB or B.

Besides other use cases, this would be useful to intuitively know if the folder was entirely uploaded or not.

DeepDiver1975 commented 11 years ago

The exact number is shown in a tool tip during 'on mouse over'

andredasilvapinto commented 11 years ago

That's right, thanks. I just got confused because the folder I was testing on is exactly 1 GB so I thought it was caused by the rounding.

Nevertheless, I think that information would be more useful if it was given without the need to move the mouse over each directory.

DeepDiver1975 commented 11 years ago

Summoning UX: @jancborchardt .....

andredasilvapinto commented 11 years ago

My suggestion would be something more along the lines of 'du -h', but it's just my opinion.

http://alvinalexander.com/unix/edu/examples/du.shtml

deHoeninger commented 11 years ago

I've to agree with @andredasilvapinto

The ">1000" isn't very usefull. And due to the fact, that a more accurate rounded value doesn't confusing a user at all, there should be no reason for those agressive information hiding.

jancborchardt commented 11 years ago

Hey folks! Regarding directories, this seems like a good point actually, good catch.

Last one seems best. Thoughts? Also @Raydiation

BernhardPosselt commented 11 years ago

I looked at reference art like google drive and dropbox. They dont show filesize at all (maybe because they depend on you paying them for space :D?)

I was thinking about stuff like game isos or bigger files like hd movies with 30 GB. do we really want to display ~30000MB? That seems to be hard to read. I'd actually vote in favor of mixed cardinalities and only use one comma digit for precision like 15.6 GB.

People are used to see this from Ads (Smartphone 8GB space) and I think expect it from a filebrowser. Also to make something useful out of that information I think its important to give the user a feedback on how full the harddisk (or quota) is currently like displaying a progressbar at the bottom.

I think the question is: Does the user want/need direct information on how big his files are. Open for discussion.

Just my 2¢

andredasilvapinto commented 11 years ago

I subscribe what Raydiation said. One of the things I immediately did was to check Dropbox's approach too.

Regarding the want/need for that information, I can only talk for myself and my opinion is already on this thread, let's see what others think.

jancborchardt commented 11 years ago

On Fri, Nov 30, 2012 at 12:01 AM, Bernhard Posselt <notifications@github.com

wrote:

I looked at reference art like google drive and dropbox. They dont show filesize at all (maybe because they depend on you paying them for space :D?)

They don’t show it because they want to make file size not matter. Just upload anything, it’ll be alright. File size introduces the constant awareness that something is big and takes up space and you might want to delete it to free up space (= also save less on Dropbox/Gdrive).

I was thinking about stuff like game isos or bigger files like hd movies with 30 GB. do we really want to display ~30000MB? That seems to be hard to read. I'd actually vote in favor of mixed cardinalities and only use one comma digit for precision like 15.6 GB.

We’d display ~30.000 then. Except we wouldn’t, because it’s a file and then it would be >1000.

People are used to see this from Ads (Smartphone 8GB space) and I think expect it from a filebrowser. Also to make something useful out of that information I think its important to give the user a feedback on how full the harddisk (or quota) is currently like displaying a progressbar at the bottom.

The GB from ads seems like a good point.

Regarding quota bar: Referencing what I said above about Dropbox and Google Drive – we don’t want to hide file size completely, but we also don’t want to push quota in people’s faces. Quota is only important if it’s close to running out, and then we can still display a notification. But it shouldn’t be a constant »HEY BUDDY YOU USE 2GB OF YOUR AVAILABLE 20GB, JUST SO YOU KNOW« (hyperbole).

I think the question is: Does the user want/need direct information on how big his files are. Open for discussion.

What I found out in initial research was that this was mainly important for knowing if it’s fast to download/upload and if it can be sent via email. So I think this is valuable enough. Of course I know what Dropbox and Google Drive do, but as mentioned above they have different motivations.

Actually now I’m leaning more again to just keeping it at >1000. If you really want to know more, just hover it. It’s not that important – especially if you just need to do it once to check if the whole folder uploaded.

BernhardPosselt commented 11 years ago

Regarding quota bar: Referencing what I said above about Dropbox and Google Drive – we don’t want to hide file size > completely, but we also don’t want to push quota in people’s faces. Quota is only important if it’s close to running out, and then we can still display a notification. But it shouldn’t be a constant »HEY BUDDY YOU USE 2GB OF YOUR AVAILABLE 20GB, JUST SO YOU KNOW« (hyperbole).

Right, totally agree with that. Is there a notification yet if the uploaded file exceeds the data limit without uploading it first?

What I found out in initial research was that this was mainly important for knowing if it’s fast to download/upload and if it can be sent via email.

Ok, i see the point in that argumentation. I'd agree with Jan under these circumstances.

DeepDiver1975 commented 11 years ago

I have to add already the '>1000' MB feels odd. "More than 1GB" would feel much better. I see to issue in mixing MB and GB.

jancborchardt commented 11 years ago

I’d say we close this because the original issue is already solved by ownCloud (»By placing the mouse over the number it could show the real size in MB or B.«) We can start on this again when there’s a better solution (atm I don’t see one) or rather a better problem.

@DeepDiver1975 Mixing in GB and putting in natural language gives way too much importance/width to the Size column. It would require units to be displayed and that would make a 1GB file look less big than a 30MB/1MB/873KB file on first glance – that’s exactly why the units are all MB without unit displayed in the first place.

andredasilvapinto commented 11 years ago

@jancborchardt oddly enough currently one thing that is, not only similar, but actually equal on first glance, is 1TB when compared with 1GB (both '>1000'). I find your argumentation not very practical (as in, it is not scalable), but who am I to disagree.

jancborchardt commented 11 years ago

@andredasilvapinto everyone is welcome to disagree and bring arguments. :)

It’s very much scalable for the moment: files above 1GB (let alone 1TB) are not very common, also because the bandwidth for up & downloading is limited. It’s mostly movies, or giant backups or what have you. Certainly not files everyday users handle. The standard storage for Dropbox is 2GB, the one for GDrive and iCloud 5 GB, just as a measure.

Once that changes, fast internet is common, providers give giant accounts to people, and our files are giant, we can just change the scale (move from MB to GB as »the unit«) and it’ll be fine. I don’t expect this to happen anytime soon though.

Hence closing this as »won’t fix«. Comments and discussion still welcome though!

andredasilvapinto commented 11 years ago

why are you talking about files? this also happens with folders, it is not that uncommon to have >1000MB directories. and this issue is especially targeted to directories, hence the name "Support directory size for directories >1000MB"

jancborchardt commented 11 years ago

Good point, hadn’t thought about folders in my reply. The exact size isn’t that important on first glance. If it’s >1000 you know enough that its not possible to download quickly, and for more details you can just hover. >1000 is just another way to say »it’s a boatload« or »too much to have a distinction between 4000 and 8000 matter«.

TL;DR file size is not that important, it’s just to indicate if it’s small, medium, big, or impossible to up/download.

voidzero commented 11 years ago

Meh. What's wrong with 10MB, 10GB et cetera?

pez252 commented 11 years ago

Displaying human readable file sizes is more useful for me, and a number of other users. I understand the reasoning behind not displaying the human readable size by default, but could it the change be implemented as an option to switch between the two options globally or per user?

I made a couple small changes on my install to display the human readable sizes that worked well.

edit core/js/js.js comment out the existing simpleFileSize function (line ~642) using // on each line or /\ on first line and **/ on last line Add your own function as follows:

function simpleFileSize(size) { return humanFileSize(size); }

edit lib/template.php comment out the existing simple_file_size function (line ~71) Add your own function as follows:

function simple_file_size( $bytes ) { return OC_Helper::humanFileSize( $bytes ); }

pez252 commented 11 years ago

The above suggested changes still work in 4.5.7.

fbjerggaard commented 11 years ago

Above still works fine in 5.0.5, and IMO should be made default, as it's just so much nicer.

jancborchardt commented 11 years ago

We closed this as won’t fix, for reasons stated above. We might look into it in the future but not now. If the aforementioned code/fix works for you that’s ok, but please let this thread rest.

jmintz commented 11 years ago

What is the reason for modifying core/js/js.js?

Seems like only editing lib/template.php as suggested above will yield the same result.