Just my 0.02$ on Fitts's Law vs. Unity (some, if not all, have already been
put forth):
I don't think one can, with 100% accuracy, apply Fitts's Law to the
Unity-interface. Reason being that Fitts's Law deals with visible,
consistent interfaces that do not change. In Unity, when an application is
On Sun, May 22, 2011 at 10:48 AM, Thorsten Wilms wrote:
> Please read it, if you have the slightest doubt about the implications of
> Fitts's Law.
In the touch / multitouch domain, corners and fits law do not play together.
i
___
Mailing list: https:
I'm well aware of that my sketch is certainly not the best solution, but I
don't think yours is either. There must be a better way to keep the panel
indicator functionality without taking up so much launcher space!
I made yet another sketch on how the visibility of such indicators could be
toggled
If you look at the mockup you'll see that the idea does not mess with the
indicators/tray-icons.
As for "always-visible-vs-menu-toggler", well, I just happen to like getting
rid of menus that go unused; consider it an extra feature, you wouldn't have
to use it, just keep the menus enabled.
If you
On Tue, May 24, 2011 at 1:35 PM, Niklas Rosenqvist
wrote:
> Like the many
> applications showing system information like "RAM: 50%, CPU: 70%" which the
> user wants to be able to see at all times without opening a lens from the
> launcher.
That's nothing most users are interested in keeping alwa
2011/5/24 GonzO Rodrigue
> On Tue, May 24, 2011 at 12:20 PM, Henrik Peytz
> wrote:
>
>
>
>> As for "always-visible-vs-menu-toggler", well, I just happen to like
>> getting rid of menus that go unused; consider it an extra feature, you
>> wouldn't have to use it, just keep the menus enabled.
>
>
2011/5/24 Ed Lin
>
> I hope I cleared that up as above. I probably should do a mockup
> myself (if have time...)
>
If you guys don't mind, would you make a full desktop-mockup of the ideas?
It's always nice to see how people see it fit into the greater whole. One
thing is how the indicators will
I'm sorry for not seeing the reason behind these mockups, all of these ideas
are exactly the same as have been stated in other ayatana threads, the only
difference is the position of the menu toggle button which was discussed in
the "Global menu in Oneiric Ocelot (11.10)" thread.
2011/5/24 Henrik
2011/5/24 Ed Lin
> I hope I cleared that up as above. I probably should do a mockup
> myself (if have time...)
I would very much like to see that, I'm having some trouble visualizing your
idea and this would help me greatly!
2011/5/24 Henrik Peytz
>
>
> 2011/5/24 Ed Lin
>
>>
>> I hope I clea
The title refers to the interface Ubuntu used initially for netbook in the
pre-Unity era.
The interface still proves to be popular despite the extremely controversial
Unity and GNOME Shell around. To improve upon this I want to suggest that
the Application lens clone the the application access int
For the sake of integration, would be my answer.
Singular ideas on how to change the interface or accomplish stuff might suck
when viewed in isolation, yet turn out to be brilliant ideas when put
together with others and viewed as a whole. This was one of my gripes with
Brainstorm, it catered only
That is true of course ;) I too enjoy working with Photoshop/GIMP to
visualize ideas, it's great fun. I will probably make a complete Unity
sketch when I know what I want from Unity 2.0 :)
2011/5/24 Henrik Peytz
> For the sake of integration, would be my answer.
> Singular ideas on how to change
A very rough sketch based on your image and parts scraped from google images...
http://i.imgur.com/WMLYk.png
On Tue, May 24, 2011 at 9:03 PM, Niklas Rosenqvist
wrote:
> 2011/5/24 Ed Lin
>> I hope I cleared that up as above. I probably should do a mockup
>> myself (if have time...)
>
> I would ve
Why can't we let the top panel stay and hold the indicators?
1. Panels/notification bars are used in *every* major OS (Windows's is odd
at the bottom), from desktops like Ubuntu and OS X to mobile platforms like
Android and iOS. It's a very familiar paradigm that people are comfortable
working wit
2011/5/24 Ed Lin
> A very rough sketch based on your image and parts scraped from google
> images...
> http://i.imgur.com/WMLYk.png
I understand your idea but to me it feels like a last resort "make it just
work" solution.
1. It takes up a really big part of the launcher. The mockup is based o
As an addition to the reply to Ed Lin:
Imagine when the launcher gets overflowed with launcher so that it stacks
them at the top and bottom, how would this work together with your design?
2011/5/24 Niklas Rosenqvist
> 2011/5/24 Ed Lin
>
>> A very rough sketch based on your image and parts scra
On Tue, May 24, 2011 at 10:39 PM, Ian Santopietro wrote:
> Why can't we let the top panel stay and hold the indicators?
>
> 1. Panels/notification bars are used in *every* major OS (Windows's is odd
> at the bottom), from desktops like Ubuntu and OS X to mobile platforms like
> Android and iOS. It
Disregarding the design for a moment, isn't the underlying problem that the
interface is supposed to support a wide range of vertical resolutions, but
doesn't?
I also have a 1920x1080 screen and I think want this layout badly, but I
also see your points on this being a mess on a smaller screen. Co
I agree, the best idea so far is moving the panel to the bottom instead of
having it on top. Though this doesn't help in improving vertical screen
space, only application functionality.
2011/5/24 Ed Lin
> On Tue, May 24, 2011 at 10:39 PM, Ian Santopietro
> wrote:
> > Why can't we let the top pa
The point I'm trying to make is that the current panel isn't broken, and
moving things like that is just change for the sake of change. When you're
trying to build a set and solid identity, that;s not a good thing.
What really makes the bottom edge so ill-suited to placing interface
elements? Is i
2011/5/25 Ian Santopietro
> Even if we did open up the top edge as opposed to the bottom edge, where
is the guarantee that app developers would take advantage of that and
actually use it?
The thing is that they already are. The majority of applications have a
top-down element priority design, e.
But don't all designers take into account the title bar of the window?
Don't all the features you talk about appear under it? Since, when
maximised, the panel is the title bar, I don't see how this is a
concern. Have I missed something?
On Wed, 2011-05-25 at 01:00 +0200, Niklas Rosenqvist wrote:
I have to say, I'm with Ian and Ello here. The 24px vertical space is only *
wasted*, i.e. not usable by any application, when you are using
non-maximized windows, and using non-maximized windows basically means you
don't need those 24px anyway. Now, when you'd move the panel to the bottom,
that's
On Tue, May 24, 2011 at 11:13 PM, Niklas Rosenqvist
wrote:
> 2011/5/24 Ed Lin
>>
>> A very rough sketch based on your image and parts scraped from google
>> images...
>> http://i.imgur.com/WMLYk.png
>
> I understand your idea but to me it feels like a last resort "make it just
> work" solution.
>
On Wed, May 25, 2011 at 1:15 AM, ello wrote:
> But don't all designers take into account the title bar of the window?
> Don't all the features you talk about appear under it? Since, when
> maximised, the panel is the title bar, I don't see how this is a
> concern. Have I missed something?
Yes,
One thing I forgot: distraction. If you have several windows open on a
desktop you'll have to move outside the window you are currently
working in and both move your eyes and the cursor across other windows
(and maybe a distracting wallpaper or a cluttered desktop). Don't
think that matters? Google
"""Maximized windows need no titlebar across the full screen edge. See
Photoshop, Office, Firefox, Chrome (on Windows)."""
But the difference is that all of those applications have title bars. The
only difference is that they have stuff in them. Firefox and Chrome have
tabs there. Office has icons
27 matches
Mail list logo
