unity-design team mailing list archive

[Renze van der kamp <renzevanderkamp@xxxxxxxxx>]

Thanks Mitja Pagon for your reply,

It seems to me it comes down to how you use your desktop, I don't use gimp
or inkscape that often and in my opinion frequently used menu items should
reside in a toolbar. My problem is that I don't know what the menu belongs
to or that the wrong menu is being displayed, so I've got a different
problem to solve and arrive at a different solution. I think the connection
of the menu with the window is far more important to me than the extra click
needed to acces an item I don't use all that often. So in my opinion for
applications I use on a daily basis  (for reference:
firefox,empathy,banshee,geany,vlc,thunderbird,writer) the extra click is not
that much of an investment. We can't please everybody and I'm not suggesting
this is an optimal sollution for everybody, but after examining my personal
usage of the desktop I think i'd like to test this solution for a while and
see how it fits my needs. Seeing as i usually use gimp maximized the extra
click could be slightly less intrusive if we'd only require a hover to
expand the menu's in the panel for programs like inkscape and gimp.

For productionwork I switch to osx  (adobe, final cut) where I sometimes
hate the idea of a global menu. I've got a multimonitor setup and when I
need to access menu's it's usually in word for mac or photoshop while
reading a webpage in chrome. The current default (and the behavior of osx)
requires the extra click already to focus the other window. For Gimp the
extra click could be a nightmare, but it already is because I'm not certain
if the menu displayed belongs to the image I'm editing or the one on my
other monitor which could also have focus.

@Toki Tahmid, no that's functionality I'd expect in the launcher, the
dropdown would hold the menubar in a vertical fashion.

Renze van der Kamp

2011/4/16 Mitja Pagon <mitja.pagon@xxxxxxxxxx>

> To understand just how counterproductive your idea is, try and imagine what
> it would be like to work with such menu in applications like GIMP or
> Inkscape, where one has to access menus often (extra click for each menu
> access), it might seem OK at first, but try doing that for hours, not only
> would it cause additional physical strain, it would be very annoying after a
> short while.
>
> What you did is actually very common mistake, and one most people do (as we
> are poor thinkers in general), is go straight to trying to solve the
> problem, without actually defining what the problem is. If you do not
> establish what the actual problem is, you cannot find a solution and once
> you find a possible solution you need to do what is called a potential
> problem/benefit analysis to figure out if your solution is any good (if it
> does not do more harm than good in the long run). It is only after you do
> that, you can find a effective solutuion to your problem (and this applies
> to all matters in life, not just UI/UX design).
>
> But as I said, do not worry, as Canonical pretty much did the same thing,
> and that's why we are having this debate.
>
> Cheers,
> Mitja
>
>
> ----- "Renze van der kamp" <renzevanderkamp@xxxxxxxxx> wrote:
> >
> >
> Hi list,
> >
> > First of all I don't have Unity installed currently and I'm not a native
> English speaker but I'd like to share an idea I've had. I'd like to discus
> combining the mockup I've quoted and the menu button as seen in the youtube
> video (and Firefox 4 on Win7). If we make the windowtitle of the window a
> button on all floating windows we achieve the goal of decluttering the
> desktop and it doesn't get into the mess of trying to put a whole menubar
> inside a tiny titlebar for small windows and it'll leave room for dragging
> the window. It doesn't require a click on the window to make it focused and
> then going back to the top panel to select an option (something I find
> myself doing all the time on osx). This means that it only requires an extra
> click on already focused windows.
> >
> > There is another advantage if multiple windows are maximized. I don't
> need to know which window is maximized and focused, I should recognize it
> from the content displayed in the window itself covering my whole screen.
> Therefore we could display the menubuttons of all maximized windows next to
> each other on the panel exposing the menu of the hidden maximized window and
> at the same time provide information on which windows are lurking beneath
> (probably going from left to right in order of being maximized (or opened),
> like tabs). These menu's cannot be used for window switching, but that's
> what the launcher is for anyway. I think the behavior of the top panel will
> be easier to understand as it now only merges the "titlebar with menu
> inside" exactly like it's seen on the window. I hope you'll understand my
> idea, but for a visual thinker I've included a mockup
> http://dl.dropbox.com/u/1286396/Ubuntu/menubuttons.png .
>
> >
> Thanks in advance for considering it.
>
> > Renze van der Kamp
> >
> > On 04/15/2011 05:45 PM, Christian Mackintosh wrote:
>
> (...) As far as I'm concerned the only sensible solution is this:
> http://www.webupd8.org/2011/02/unity-mockup-menu-integrated-in-window.html, which I will keep banging on about because it's so brilliant. (...)
> >
>
> Christian Mackintosh
> >
> >
>
>
> >
>
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~ayatana
> > Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~ayatana
> > More help   : https://help.launchpad.net/ListHelp
> >
>