[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: Re: // Death to KMenu, Long Live Kicker (Plasma) //
From: julian oliver <julian () selectparks ! net>
Date: 2005-07-23 19:27:54
Message-ID: 20050723192754.GD27064 () localhost
[Download RAW message or body]
..on Sat, Jul 23, 2005 at 10:22:56AM -0400, seele@obso1337.org wrote:
>
> i am actually working on gathering a set of research to help develop anew
> or alternative to k menu. There is a high importance for it being
> research based and not many Interface decisions in KDE have been like
> that. (or usability professional's opinion does not mean it is research
> based)
>
> if you have any resources you would like to share, I would be happy to
> collect and compile then in my Study. I plan to present several
> alternatives to the kmenu at akademy so developers will have an
> opportunity to give feedback and ask questions
Great, i'll see if i can cobble together a working demo in OpenGL
that at least describes the movement and mouse control. I'll supply
notes time permitting.
That said my cursory proposal seeks to move away from statically located menu's
altogether, rather providing access to application execution 'under the
fingertips' of the user wherever they are on the desktop. Whether this
constitutes a contribution to KMenu is up to you.
I should also note that the idea of using Konqueror as an menu editor
doesn't discard using Konqueror as a menu system in itself for executing
rarely used (non 'wheel' docked) applications. From what I have seen
OSX works a little more this way (where ~/Applications is a location
containing symlinks and statically linked binaries).
Julian
>
> >
> > This is a proposal that seeks to make a decisive break from the current
> > topography of the KDesktop. I've spent alot of time watching my students
> > work with KDE. These suggestions come as a result both from what I've
> > noticed, and my own experiences on the KDesktop (which I'm a big fan of by
> > the way).
> >
> > I'd like to have some mockups to better explain what I'm on about, in the
> > meantime text will have to do. If there are enough folk that have a hard
> > time visualising what I'm talking about, perhaps I can make time to
> > produce a 2D working mockup in OpenGL.
> >
> > Kill KMenu. Liberate Kicker:
> >
> > Movement, especially mouse movement on the KDesktop is heavily imbalanced.
> > The user is always drawn down to the bottom of the screen (a kind of
> > gestural gravity or heaviness), in particular the bottom left corner to
> > perform basic find and execute tasks in the KMenu.
> >
> > In order to avoid using the pop-up KMenu, the user adds panel items for
> > the sake of convenience, but this convenience brings with it a vector
> > always oriented toward the bottom of the desktop, and an overloaded
> > graphical scape; the kicker is overworked. Not only is it a notification
> > site, but also a task bar, a pager, a systray et al. What is left of the
> > kicker after all this is usually loaded with icons, at best menu applets.
> >
> > I propose the kicker be resigned from any responsibility as a site of
> > application icons, and application menu's, instead remain doing what it
> > does best, serve as a utility and notification bar; a visually distinct
> > contact point for keeping in touch with what's going on. KMenu and
> > application icons produce a large volume of cognitive noise on the
> > KDesktop, it doens't need to be this way. The KDesktop can be a calm
> > place.
> >
> > A New Approach to Application management and Execution: KWheel
> >
> > Don't get too hung up on the 'wheel' part of KWheel, it's just a working
> > title. It isn't 'round' in any way, though it has a circular nature in the
> > sense of its use.
> >
> > Anyway this is what I envisage.
> >
> > My current 'desktop' of choice at home is the very innovative WMII
> > http://wmi.modprobe.de). WMII has a wonderful approach to application
> > selection and execution, one hits a couple of keys and the entire panel
> > (bar) suddenly becomes replaced with all the applications in ones path.
> > Using completion, one starts typing the application highlights. <ENTER>
> > executes. It's extremely fast, clean, intuitive and sensible. I can also
> > use the <|> cursor keys to move through this menu, the current selection
> > always visible with colour highlighting.
> >
> > However this isn't what I propose for KDE, WMIMENU (as it's called) uses
> > no mouse input,
> > and it's the problematically recurrent long-distance mouse targets in KDE
> > that needs to be undone.
> >
> > Taking a leaf from WMIMENU I'd like to propose a floating application bar,
> > that sits under a keybind (perhaps the Windows Key) and uses left and
> > right mouse movement to scroll through the icons. This 'wheel' would
> > appear as a horizontal application dock under the current position of the
> > cursor when ever this keybind was used. When this keybind is pressed and
> > the mouse moved, the entire desktop would desaturate slightly (becoming
> > innaccessible) and this large colourful application bar would appear
> > immediately under the cursor at it's current position.
> >
> > The 'wheel' aspect of this proposition is derived from the scroll function
> > of this floating dock, as it has a 'physics' to it that is a little like a
> > gearing system. When the user moves the mouse to the left slowly, the
> > icons scroll to the right slowly and vice versa. When the user moves the
> > mouse faster, the icons scroll further before dampening off. All mouse
> > movement used as input for driving the wheel is one dimensional, the X
> > axis only. The current selection is always in the absolute center of the
> > wheel and using SVG scaling, is larger than the rest. The selection is
> > executed with a LMB click. Icons at either end of the wheel at any given
> > time will return on the other end of the wheel when 'scrolled off' the end
> > they are closest to. KWheel can have an infinite number of icons, what is
> > not on screen can be scrolled into view. A small text feild could also be
> > invoked above this bar (with <TAB>) and you could use text completion to
> > scroll the icon into view, left click or <ENTER> to execute.
> >
> > The point here is that the user should not have to move the mouse to
> > access their applications, thus cutting down time and avoiding the mental
> > segmentation involved in 2dimensional mouse movements to locate icons and
> > execute applications.
> >
> > Here, the kdesktop is being used in a layered fashion, not as a flat,
> > 2Dimensional landscape with limited surface area. By layering and visually
> > delimiting functionality using simple transparencies and desaturations the
> > 'real estate' of the screen develops a '3 dimensional' component -
> > something many applications (Gimp, Blender,) but few desktops do.
> >
> > Finally, graphically speaking, this 'KWheel' could even reference KDE
> > Gears logo (it would perhaps suit quite well)
> >
> > Editing KWheel.
> >
> > One thing that really frustrates my students is submenus popping up and
> > fanning out of KMenu. Even after a month of daily use they are still
> > 'backtracking' with the mouse to find the parent menu they want before
> > continuing. The slightest miscalculation and you're in the wrong section.
> > I say get rid of this pop-up, snakes and ladders menu hierachy altogether,
> > at least where mouse input is concerned. It's too 'fiddly'. Instead I
> > envisage using Konqueror as an application menu editor. Applications
> > appear in folders and can be dragged and dropped around freely. At any
> > point one could RMB-->Add To Wheel, immediately plonking it in the ever
> > hidden wheel ready to be used when needed. Secondly this would shortcut
> > icons forever competing for attention against the important work of the
> > kicker, to notify, to alert, to present current tasks and give feedback as
> > to the system status. Why pollute beautiful, graphically innovative work
> > like this http://img335.imageshack.us/my.php?image=taskmockupback36rr.png
> > with a plethora of third-party application icons?
> >
> > It's likely this has been proposed or considered before in some shape or
> > form. If that's the case, then think of this as underlining a few issues I
> > see with KDE3.4 in classroom situations, while supporting efforts to
> > evolve beyond KMenu.
> >
> > Julian
> >
> > --
> > _ _ _
> > ___ ___| |___ __| |_ _ __ __ _ _ _| |__ ___
> > (_-</ -_) / -_) _| _| '_ \/ _` | '_| / /(_-<
> > /__/\___|_\___\__|\__| .__/\__,_|_| |_\_\/__/
> > |_http://selectparks.net
> >
> > Artist in Residence IT University of Copenhagen
> > Department of Digital Aesthetics and Communication
> > Rued Langgaards Vej 7
> > DK-2300 København S
> > http://game.itu.dk
> > skype: julianoliver
> >
> > NB: email sent in HTML format will not be read.
> >
> > _______________________________________________
> > kde-usability mailing list
> > kde-usability@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-usability
> >
>
>
> _______________________________________________
> kde-usability mailing list
> kde-usability@kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
--
_ _ _
___ ___| |___ __| |_ _ __ __ _ _ _| |__ ___
(_-</ -_) / -_) _| _| '_ \/ _` | '_| / /(_-<
/__/\___|_\___\__|\__| .__/\__,_|_| |_\_\/__/
|_http://selectparks.net
Artist in Residence IT University of Copenhagen
Department of Digital Aesthetics and Communication
Rued Langgaards Vej 7
DK-2300 København S
http://game.itu.dk
skype: julianoliver
NB: email sent in HTML format will not be read.
_______________________________________________
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