[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Action icons in menus
From:       Miha Čančula <miha.cancula () gmail ! com>
Date:       2010-12-24 20:53:13
Message-ID: AANLkTi=k6EvoWiEGyF1a0hvbB8ZMiMSKMeVkaNBDRPpX () mail ! gmail ! com
[Download RAW message or body]

2010/12/24 Celeste Lyn Paul <celeste@kde.org>

> This is a very interesting concept, but not necessarily for context
> menus. Imagine this design proposal as a first step towards merging
> window menu and toolbars, not too disimilar from the Microsoft ribbon.
> One weakness with the ribbon is that it limits the amount of
> functionality by what can graphically fit in the ribbon interface.
>
> Instead of going pure graphics, you could merge frequently used tasks
> (graphics) with extended functions and features (text menu items).
> This would preserve the amount of functionality in an application
> (Microsoft stripped out some features or moved them to different
> places in order to fit them in the ribbon). At the same time, we would
> have an updated look and feel to our windowing concept that maximizes
> common interactions.
>
> I think something like this could also be an interesting alternative
> to what IE7 does by providing minimal toolbar buttons and menu items,
> and hiding everything else. In this design, additional functionality
> would be on a true "second layer of disclosure" rather than "hidden
> away".
>
> Anyway, just some thoughts. I don't want to discount the design simply
> because of a few minor issues, because it is still in the conceptual
> stage. We don't want to shoot down ideas like this too early in the
> design process, otherwise we will never innovate.
>
> Just some thoughts.
>
I've just setup a trunk kdelibs build on my home computer so I can show some
examples of how this would look in both popups and applications menus.
However, I won't be home for the holidays and I won't be able to work on
this this year.

[Attachment #3 (text/html)]

<div class="gmail_quote">2010/12/24 Celeste Lyn Paul <span dir="ltr">&lt;<a \
href="mailto:celeste@kde.org">celeste@kde.org</a>&gt;</span><br><blockquote \
class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, \
204, 204); padding-left: 1ex;"> This is a very interesting concept, but not \
necessarily for context<br> menus. Imagine this design proposal as a first step \
towards merging<br> window menu and toolbars, not too disimilar from the Microsoft \
ribbon.<br> One weakness with the ribbon is that it limits the amount of<br>
functionality by what can graphically fit in the ribbon interface.<br>
<br>
Instead of going pure graphics, you could merge frequently used tasks<br>
(graphics) with extended functions and features (text menu items).<br>
This would preserve the amount of functionality in an application<br>
(Microsoft stripped out some features or moved them to different<br>
places in order to fit them in the ribbon). At the same time, we would<br>
have an updated look and feel to our windowing concept that maximizes<br>
common interactions.<br>
<br>
I think something like this could also be an interesting alternative<br>
to what IE7 does by providing minimal toolbar buttons and menu items,<br>
and hiding everything else. In this design, additional functionality<br>
would be on a true &quot;second layer of disclosure&quot; rather than \
&quot;hidden<br> away&quot;.<br>
<br>
Anyway, just some thoughts. I don&#39;t want to discount the design simply<br>
because of a few minor issues, because it is still in the conceptual<br>
stage. We don&#39;t want to shoot down ideas like this too early in the<br>
design process, otherwise we will never innovate.<br>
<br>
Just some thoughts.<br></blockquote><div>I&#39;ve just setup a trunk kdelibs build on \
my home computer so I can show some examples of how this would look in both popups \
and applications menus. However, I won&#39;t be home for the holidays and I won&#39;t \
be able to work on this this year. <br> </div></div>



[prev in list] [next in list] [prev in thread] [next in thread]