[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: Re: [KDE Usability] Users cannot find where to "safely remove" USB
From: Hans Chen <hanswchen () gmail ! com>
Date: 2010-05-07 8:23:49
Message-ID: y2pc59230381005070123ia10e2f1bw5d06bac3c31a7b9c () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi all,
I'm sorry for bringing this up again, but I skimmed through the posts (there
are quite many) and did a search for 'context' but still couldn't find any
convincing arguments against it. I would appreciate if someone could fill me
in with what I've missed.
Against context menu:
- Clutter / Duplication of features
- Doesn't work on touch devices
- Some examples, such as iTunes, don't have a context menu for unmounting
devices
- If the unmount button was shown all the time, it wouldn't be a problem
Personally I'm in favor for adding a context menu. First of all, it would be
more consistent with Dolphin - or do some of you propose that the context
menu should be removed from Dolphin if it gets an "eject" button?
I don't believe that it adds unnecessary clutter. As others have noted,
there are already many irrelevant items in the context menu (such as Unlock
Widgets). Of course this doesn't justify adding another irrelevant one, but
in my opinion duplicating an action isn't necessary bad - this is seen in
other parts of Plasma. For example, consider an unlocked panel. You can
access the panel toolbox by clicking on the "cashew", but you can also right
click on the panel -> Panel Options -> Panel Settings. As another Plasma
example, you'll find "Unlock Widgets" in the Tool Box but also (often) when
right clicking on the desktop or panel.
I agree that we should keep other devices in mind, but that doesn't mean
that we have to limit ourselves to them. I'm not used to touch devices so I
won't discuss how to make it clearer in that case, but the suggestion to
always show the eject button sounds good in theory.
Now, adding a context menu item has an added benefit in my opinion - it
could show a disabled item with the text "Device can be safely removed" or
something similar when a device isn't mounted. From my limited experience
(family members and a few friends), some persons (a majority in my case)
don't realize that they can remove the device if the eject button isn't
shown and start looking for a "safely remove" option.
As a funny sidenote, and absolutely not used as an argument, I've never seen
a Windows user unmount a device from iTunes - they always go to the "safely
remove device" thingy in the system tray.
With best regards,
Hans Chen
On Thu, May 6, 2010 at 17:02, Dotan Cohen <dotancohen@gmail.com> wrote:
> Alright, it took some time but I showed the mockup to six users, and
> all agreed that they would now be able to find the eject buttons! Here
> is the bug, please comment on it:
>
> https://bugs.kde.org/show_bug.cgi?id=236586
>
> --
> Dotan Cohen
>
> http://bido.com
> http://what-is-what.com
> _______________________________________________
> kde-usability mailing list
> kde-usability@kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
>
[Attachment #5 (text/html)]
Hi all,<br><br>I'm sorry for bringing this up again, but I skimmed through the \
posts (there are quite many) and did a search for 'context' but still \
couldn't find any convincing arguments against it. I would appreciate if someone \
could fill me in with what I've missed.<br> <br>Against context menu:<br>- \
Clutter / Duplication of features<br>- Doesn't work on touch devices<br>- Some \
examples, such as iTunes, don't have a context menu for unmounting devices<br>- \
If the unmount button was shown all the time, it wouldn't be a problem<br> \
<br>Personally I'm in favor for adding a context menu. First of all, it would be \
more consistent with Dolphin - or do some of you propose that the context menu should \
be removed from Dolphin if it gets an "eject" button?<br> <br>I don't \
believe that it adds unnecessary clutter. As others have noted, there are already \
many irrelevant items in the context menu (such as Unlock Widgets). Of course this \
doesn't justify adding another irrelevant one, but in my opinion duplicating an \
action isn't necessary bad - this is seen in other parts of Plasma. For example, \
consider an unlocked panel. You can access the panel toolbox by clicking on the \
"cashew", but you can also right click on the panel -> Panel Options \
-> Panel Settings. As another Plasma example, you'll find "Unlock \
Widgets" in the Tool Box but also (often) when right clicking on the desktop or \
panel.<br> <br>I agree that we should keep other devices in mind, but that \
doesn't mean that we have to limit ourselves to them. I'm not used to touch \
devices so I won't discuss how to make it clearer in that case, but the \
suggestion to always show the eject button sounds good in theory.<br> <br>Now, adding \
a context menu item has an added benefit in my opinion - it could show a disabled \
item with the text "Device can be safely removed" or something similar when \
a device isn't mounted. From my limited experience (family members and a few \
friends), some persons (a majority in my case) don't realize that they can remove \
the device if the eject button isn't shown and start looking for a "safely \
remove" option. <br> <br>As a funny sidenote, and absolutely not used as an \
argument, I've never seen a Windows user unmount a device from iTunes - they \
always go to the "safely remove device" thingy in the system \
tray.<br><br>With best regards,<br> Hans Chen<br><br><div class="gmail_quote">On Thu, \
May 6, 2010 at 17:02, Dotan Cohen <span dir="ltr"><<a \
href="mailto:dotancohen@gmail.com">dotancohen@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; \
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Alright, it took some \
time but I showed the mockup to six users, and<br> all agreed that they would now be \
able to find the eject buttons! Here<br> is the bug, please comment on it:<br>
<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=236586" \
target="_blank">https://bugs.kde.org/show_bug.cgi?id=236586</a><br> <div \
class="im"><br>
--<br>
Dotan Cohen<br>
<br>
<a href="http://bido.com" target="_blank">http://bido.com</a><br>
<a href="http://what-is-what.com" target="_blank">http://what-is-what.com</a><br>
</div><div><div></div><div \
class="h5">_______________________________________________<br> kde-usability mailing \
list<br> <a href="mailto:kde-usability@kde.org">kde-usability@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-usability" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-usability</a><br> \
</div></div></blockquote></div><br>
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic