[Owncloud] Please put MB after the filesize in the "Files" view

Thu Oct 13 17:29:16 UTC 2011

On Thu, October 13, 2011 18:54, Danial Bulloch wrote:
> I completely agree that the defaults should the most sensible, but I
> disagree that removing configuration is a good thing. I like the only
> showing MB part, it's prettier than mixed units, but it also has
> issues when files are in the kb or middle to upper GB range. Sure,
> these days the biggest most files come is 4-8GB, so that isn't so big
> of an issue. I do think the roll over for better scoped units is a
> good idea, but personally I still think putting MB next to the file is
> necessary for usability. When talking length, for example, you always
> say "50 meters", even when it's clear that the object isn't 50mm or
> 50km away. When you are stating a measurement it is almost always best
> to state the units.

The comparison to distance is not really fitting as that is out of the
context of a specific scope. If you talk about a room, it’s clear that you
mean metres – if you talk about distance between cities or really anything
else above, it’s kilometres.

Better example: When talking about speed, people just say "I drove 180 on
the Autobahn" – meaning km/h.

Most files at the moment can be characterized very well in the spectrum
from 0.1 MB to 1000 MB. Everything above is either a movie or a cd image
or some big software package. And there you don’t really care if it’s 4.5
GB or 5 GB – you see through the >1000 that it is really big. If you do,
you can still just hover it. Because the big majority of files are <1000
MB, we will not display a unit.

Usability and interface design is not personal opinion but based on
research and insights of human behavior. I did several usability tests
with ownCloud and no one even bothered about the file size at all.

If you’re interested in conducting usability tests, feel free to check out
my thesis: http://jancborchardt.wordpress.com/usability-in-free-software/

I’ll end this discussion with a very nice read about free software
interfaces (from 2002, mind you):
http://ometer.com/free-software-ui.html

"I find that if you're hard-core disciplined about having good defaults
that Just Work instead of lazily adding preferences, that naturally leads
the overall UI in the right direction. Issues come up via bugzilla or
mailing lists or user testing, and you fix them in some way other than
adding a preference, and this means you have to think about the right UI
and the right way to fix problems.

Basically, using preferences as a band-aid is the root of much UI evil.
It's a big deal and a big change in direction for free software that GNOME
has figured this out."

– Havoc Pennington

> On Thu, Oct 13, 2011 at 3:43 AM, Jan-Christoph Borchardt
> <jan at unhosted.org> wrote:
>> On Thu, October 13, 2011 05:06, Danial Bulloch wrote:
>>> I noticed that afterwards. I suppose I can see the logic, but I
>>> disagree that it is a good idea. Standard practice, of nearly every
>>> file manager in the history of file managers is to show the units next
>>> to it.
>>
>> Exactly, current standard practice for nearly every file manager is to
>> mix
>> up the units – which is stupid. It makes the column nearly useless
>> because
>> you can only check on the value for a specific file but not compare to
>> the
>> others. We will not copy bad design just to achieve "consistency".
>> Currently, we even give bigger files a darker shade so that they are
>> even
>> easier identifiable (same for relative dates).
>>
>>
>>> When I don't see MB, I just see a number that has an unknown
>>> meaning. I realize that you will quickly learn that it is always in
>>> MB, but it still feels off to me, redundant or not.
>>
>> You’ll get used to it. I hope that other file management programs follow
>> the lead.
>>
>> I’m happy to see that most Dolphin file manager screenshots I see use
>> the
>> icon view as default. This would be a very nice thing for ownCloud 3 for
>> sure. There it doesn’t even show the size or date.
>>
>>
>>> I don't know how
>>> granular the settings are going to going to get, but I'd be happy with
>>> a toggle option somewhere in the main settings or even a config file
>>> somewhere.
>>
>> Ideally the number of settings approaches zero. There will be no
>> settings
>> for everything, especially not interface preferences.
>>
>> Software is made to make people’s lives easier. It should be well
>> designed
>> from the outset and use sensible defaults.
>>
>>
>>> I'm not a developer and don't plan on submitting code, so
>>> if no unit is the way you guys want it, that's fine with me, just
>>> thought I would share my thoughts on the topic.
>>>
>>> On Wed, Oct 12, 2011 at 6:48 PM, Jan-Christoph Borchardt
>>> <jan at unhosted.org> wrote:
>>>> That is intended. The file size _always_ uses megabyte as a unit hence
>>>> it
>>>> would be useless to put it there because you know after the first time
>>>> checking. Detailed info is available on hover. Also, when you hover
>>>> the
>>>> relative date, the absolute date will appear.
>>>>
>>>> On Wed, October 12, 2011 22:51, Danial Bulloch wrote:
>>>>> I was looking at my owncloud list of files and noticed that the
>>>>> "size"
>>>>> column is just a number. I know that it doesn't make a big
>>>>> difference,
>>>>> but putting MB at the end makes it clear what that column is without
>>>>> looking at the header, and the header doesn't specify what units the
>>>>> size is in(1.21 Jiggabits?). If there is a reason that it isn't
>>>>> there(besides maybe to save space), I'd be interested to know.
>>>>>
>>>>> Sorry if this isn't the right place to make feature requests, I
>>>>> didn't
>>>>> find anything on the site that suggested a better place. Also, I'd
>>>>> submit a patch or something if I was the programmer type, but I can't
>>>>> program my way out of a paper bag. I tried once, nearly suffocated,
>>>>> which is actually harder that one might imagine with a paper bag.
>>>>> _______________________________________________
>>>>> Owncloud mailing list
>>>>> Owncloud at kde.org
>>>>> https://mail.kde.org/mailman/listinfo/owncloud
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>