Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Mark Shuttleworth]

On 28/04/10 00:19, Jeremy Nickurak wrote:
> I would assume that the window controls won't exist in this scenario...
>
> Am I correct in assuming that menus will only go into the top panel if
> the window is maximized, such that its window controls are hidden by
> maximus?

Neither is right, I'm afraid.

When the window is not maximised, the menu will be in the panel, and the
window title (and window controls) will be in the window.

When the window is maximised, the panel will contain:

 - the window controls (from the left, just after the Ubuntu icon)
 - the window title
 - the indicators (aligned right)

When you mouse towards the window title, or press Alt, it will be
replaced by the menu.

Mark



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Reducing Resistance to Change

[Jim Rorie]

On Tue, 2010-04-27 at 23:55 -0500, Diego Moya wrote:

> In the cases I've witnessed, the hyperbole works more like "we've
> broken the current workflow for some real existing users in benefit of
> some hypothetical newcomers that could or could not use the new
> feature. And we don't provide a way for advanced users to restore
> their previously used workflow because, well, options are always bad".
> You won't overcome this perception with better language, because users
> in this situation have a valid concern that won't go away with an
> explanation.
> 
> I'm the first one to defend a simplified design for entry-level to
> average users even if it doesn't support expert features. But this
> kind of design should be only for new features and never, ever be put
> in place of a previous design already in use. This is the golden rule
> of computing - if ain't broke, don't fix it.


I couldn't agree with this more. It's the core problem, IMO.

However, the "options are always bad" isn't really fair to the UX team.
The stated reason is to limit options for testability reasons, which I
respect.  But, it's badly communicated.  

The result is the same.  The advanced users have to rely on themselves
or the community to restore lost functionality.




smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Omer Akram]

> When the window is maximised, the panel will contain:
>
> - the window controls (from the left, just after the Ubuntu icon)
> - the window title
> - the indicators (aligned right)

Hmm. How will we switch between running apps then?
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Mark Shuttleworth]

On 28/04/10 11:48, Omer Akram wrote:
> > When the window is maximised, the panel will contain:
> >
> > - the window controls (from the left, just after the Ubuntu icon)
> > - the window title
> > - the indicators (aligned right)
>
> Hmm. How will we switch between running apps then?

We'll address that separately.

Mark


signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Reducing Resistance to Change

[Martin Owens]

On Tue, 2010-04-27 at 23:55 -0500, Diego Moya wrote:
> Are you willing to compromise
> the design decisions and adapt to those multiple considerations, or
> are you going to push one "pure" solution for its expected benefit in
> some specific cases? It's hard to balance both ways 

Yes it is hard and that's where you need courage. But I disagree that
you have to pick one or the other. You may prefer one over the other,
but that's not really getting into the ideas properly if they both
remain the same as they went in.

A dish dirties the water as much as the water cleans the dish.

Martin,


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Alex Lourie]

This all sounds great for saving screen space, but it is hard to understand
how usable it would be without
actual examples or mockups.

I'll wait for the live examples then

Thanks,
Alex.

On Wed, Apr 28, 2010 at 1:54 PM, Mark Shuttleworth  wrote:

>  On 28/04/10 11:48, Omer Akram wrote:
>
> > When the window is maximised, the panel will contain:
> >
> > - the window controls (from the left, just after the Ubuntu icon)
> > - the window title
> > - the indicators (aligned right)
>
>  Hmm. How will we switch between running apps then?
>
>
> We'll address that separately.
>
> Mark
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Diego Moya]

On 28 April 2010 05:26, Mark Shuttleworth wrote:
> When you mouse towards the window title, or press Alt, it will be
> replaced by the menu.

How is this expected to work on touchscreens, where the pointing
device lacks a real mouseover action? Will it rely on a hard key being
available?

I know my Nokia tablet does this to change between fulscreen and panel
modes, and it somehow works. But it's hardly discoverable (when I lend
the device to a friend in fullscreen mode, they'll never figure out
how to get out of it) and it lacks the direct approach of just
interacting with the panel in its current screen position.

Will you consider including a switch button in the title bar so that
the user can switch between modes with a click instead of a mouseover?

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Mark Shuttleworth]

On 28/04/10 14:21, Diego Moya wrote:
> On 28 April 2010 05:26, Mark Shuttleworth wrote:
>   
>> When you mouse towards the window title, or press Alt, it will be
>> replaced by the menu.
>> 
> How is this expected to work on touchscreens, where the pointing
> device lacks a real mouseover action? Will it rely on a hard key being
> available?
>   

In cases where the touch screen is supplementary (i.e., you have a
notebook, with mouse and keyboard *and* touch screen), folks will use
the keyboard or mouse when using the menu.

In pure-touch cases (like tablets) we would not recommend using apps
which require the use of traditional menus at all.

Mark



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Walter Wittel]

For toggle when using touch maybe staking out some OS "reserved" gesture/s
early in the game would be worthwile. For instance on some Android apps
press-hold brings up a menu. Unfortunately this isn't always the case so it
is less useful / discoverable.

On Apr 28, 2010 6:25 AM, "Mark Shuttleworth"  wrote:

On 28/04/10 14:21, Diego Moya wrote: > On 28 April 2010 05:26, Mark
Shuttleworth wrote: > >> When...
In cases where the touch screen is supplementary (i.e., you have a
notebook, with mouse and keyboard *and* touch screen), folks will use
the keyboard or mouse when using the menu.

In pure-touch cases (like tablets) we would not recommend using apps
which require the use of traditional menus at all.

Mark


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] posting

[Kai Aeberli]

Hello,

I have been trying to post a message to the ayatana mailing list, but it
doesnt show up in the archives. Why is that?

Best regards,

Kai
-- 
This message was sent from Launchpad by the user
Kai Aeberli (https://launchpad.net/~kai.aeberli)
using the "Contact this team" link on the Ayatana Discussion team page.
For more information see
https://help.launchpad.net/YourAccount/ContactingPeople

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Jeremy Nickurak]

Ah.

This is an idea that's been debated alot, and in general, rejected, outside
of macos circles. Decoupling the menu from the application window means you
have to move your mouse from an application window, through an unrelated
desktop region, up to a seperate region of the screen, which means it's not
at all visually obvious that the menu at the top of the screen has
*anything* to do with the application.

What about dialog windows that don't have menus, and don't get maximized? In
that case, the top panel will just have a large empty space?

On Wed, Apr 28, 2010 at 04:26, Mark Shuttleworth  wrote:

> On 28/04/10 00:19, Jeremy Nickurak wrote:
> > I would assume that the window controls won't exist in this scenario...
> >
> > Am I correct in assuming that menus will only go into the top panel if
> > the window is maximized, such that its window controls are hidden by
> > maximus?
>
> Neither is right, I'm afraid.
>
> When the window is not maximised, the menu will be in the panel, and the
> window title (and window controls) will be in the window.
>
> When the window is maximised, the panel will contain:
>
>  - the window controls (from the left, just after the Ubuntu icon)
>  - the window title
>  - the indicators (aligned right)
>
> When you mouse towards the window title, or press Alt, it will be
> replaced by the menu.
>
> Mark
>
>


-- 
Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =-
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Diego Moya]

On 28 April 2010 08:24, Mark Shuttleworth wrote:
> On 28/04/10 14:21, Diego Moya wrote:
>> How is this expected to work on touchscreens, where the pointing
>> device lacks a real mouseover action? Will it rely on a hard key being
>> available?
> In cases where the touch screen is supplementary (i.e., you have a
> notebook, with mouse and keyboard *and* touch screen), folks will use
> the keyboard or mouse when using the menu.

Notebooks don't always have a mouse connected, and then you won't take
advantage of the touch screen? My point is that the design should
degrade gracefully to be usable for basic cases and take advantage of
the available input devices, even if their exact features vary
slightly (i.e. mouse versus stylus pointing).

I'm thinking more of tablet-like smartphones and notebooks with a
sliding, detachable or bluetooth keyboard, which is available for
advanced use cases but shouldn't be relied upon for the basic
interaction idioms.

This strategy would also be great for accessibility. Think people with
disabilities using non-standard pointing devices. A design whose basic
idioms are suitable for touch-screen only would be easier to adapt to
the needs of their environment than one that depends on the more
powerful mouse interactions.


>
> In pure-touch cases (like tablets) we would not recommend using apps
> which require the use of traditional menus at all.


What is the planned scope for Ubuntu mobile? This sound as if you're
planning to support only netbooks in your mobile platform, and maybe
have a different environment for tablets with applications
specifically tailored to mobile usage. With no accommodation for
applications migrated from the desktop. Are you not looking for a
design that would scale to work on both environments, with or without
mouse-and-keyboard?

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Integrating Application Search & Install

[Tyler Brainerd]

If the goal of all this is to directly connect the user quickly with
their files and programs, then adding programs that are not currently
installed will only add clutter and messiness, making it more
difficult to find their files and programs, and effectively making
sure that no one will use this. If you're stuck on the idea of using
this little search programs that are not installed, then add a button
on the bottom that says "search ubuntu software center" and have
clicking on it open the software center with the term in the search
box. But don't include apps that aren't installed, that will only slow
it down and make it messy.

On Apr 26, 2010, at 12:51 PM, Jan-Christoph Borchardt
 wrote:

> On 26 April 2010 17:07, Frederik Nnaji 
> wrote:
>> On Mon, Apr 26, 2010 at 16:27, Luke Benstead 
>> wrote:
>>> I visualize the window only appearing when someone starts
>>> typing into the box and the results would filter down. When the user
>>> clears the box (or presses enter to execute the top entry) the
>>> window
>>> would disappear.
>>
>> how about offering repository stuff, when the user decides to
>> specifically look for apps!?
>> then one could bring in some Ubuntu Software Center code to install
>> whatever the user found here..
>
> The idea to integrate the Software Center directly is great!
>
> That way it feels like having every app already on the computer
> → immense lowering of entry barrier and more discoverability.
>
>
>> this FAsT (FAYT) search box will search not only apps but also
>> places,
>> files, eventually people..
>> we should find it a pretty name, that will guide us in designing
>> it ;)
>>
>> i suggest "find as you type.." for the moment :D
>
> I suggest »Finder«. ;P
>
> No really, the FAST way is great – but where do we draw the line
> between Software Center search and places, files, people?
>
> I think we should do it right the first time and make a global search
> that integrates searching *everything* (of interest for you) on the
> computer as well as stuff not yet on it – such as easily downloadab
> le
> apps in the Software Center.
>
> Being able to install applications on the fly could be a game changer.
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Skipping Multiple songs?

[Chow Loong Jin]

On Wednesday 28,April,2010 10:47 PM, Frederik Nnaji wrote:
> On Tue, Apr 27, 2010 at 20:58, Jan Claeys  > wrote:
> 
> Obviously, shoehorning everything into standard menu items shouldn't be
> our goal...
> 
> > Do others often try to skip multiple songs?
> > Is there a way to make this easier? [Probably, right-click to skip and
> > not close the menu?]
> 
> I think the drop-down from the "musicplayer indicator" should show the
> currently playing song (maybe with an album picture?), the location in
> the song (maybe also as a slider that can be used to seek?), and widgets
> for the basic operations you will want to do (skip, play/pauze,
> rate, ...?).
> 
> 
> perhaps like this? (mockup attached..)

That mockup looks really similar to the large tooltips that Rhythmbox and
Banshee were having prior to app-indicator-ification.



-- 
Kind regards,
Chow Loong Jin



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Tyler Brainerd]

In which case they probably ought not to be using the netbook remix
version. The standard desktop is probably going to suit their needs
better, with just the custom launcher menu.

On Apr 28, 2010, at 8:41 AM, Diego Moya  wrote:

> On 28 April 2010 08:24, Mark Shuttleworth wrote:
>> On 28/04/10 14:21, Diego Moya wrote:
>>> How is this expected to work on touchscreens, where the pointing
>>> device lacks a real mouseover action? Will it rely on a hard key
>>> being
>>> available?
>> In cases where the touch screen is supplementary (i.e., you have a
>> notebook, with mouse and keyboard *and* touch screen), folks will use
>> the keyboard or mouse when using the menu.
>
> Notebooks don't always have a mouse connected, and then you won't take
> advantage of the touch screen? My point is that the design should
> degrade gracefully to be usable for basic cases and take advantage of
> the available input devices, even if their exact features vary
> slightly (i.e. mouse versus stylus pointing).
>
> I'm thinking more of tablet-like smartphones and notebooks with a
> sliding, detachable or bluetooth keyboard, which is available for
> advanced use cases but shouldn't be relied upon for the basic
> interaction idioms.
>
> This strategy would also be great for accessibility. Think people with
> disabilities using non-standard pointing devices. A design whose basic
> idioms are suitable for touch-screen only would be easier to adapt to
> the needs of their environment than one that depends on the more
> powerful mouse interactions.
>
>
>>
>> In pure-touch cases (like tablets) we would not recommend using apps
>> which require the use of traditional menus at all.
>
>
> What is the planned scope for Ubuntu mobile? This sound as if you're
> planning to support only netbooks in your mobile platform, and maybe
> have a different environment for tablets with applications
> specifically tailored to mobile usage. With no accommodation for
> applications migrated from the desktop. Are you not looking for a
> design that would scale to work on both environments, with or without
> mouse-and-keyboard?
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Finger Swipe Gadgets

[Bob Hazard]

My voice is my passport

On 28 April 2010 01:20, Chow Loong Jin  wrote:
> On Wednesday 28,April,2010 07:05 AM, Benjamin Humphrey wrote:
>> It would be kickass if you could grin at your computer to make it unlock.
>
> It would be really funny to watch someone pulling different variants of a face
> at the computer, failing and retrying due to shortcomings in the face
> recognition software. :-D
>
> --
> Kind regards,
> Chow Loong Jin
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Integrating Application Search & Install

[Diego Moya]

On 28 April 2010 10:50, Tyler Brainerd wrote:
> If the goal of all this is to directly connect the user quickly with
> their files and programs, then adding programs that are not currently
> installed will only add clutter and messiness,

The application menu has also the goal to let the user discover the
applications available in the system.

I like the idea of showing installable applications in the search
results, but Tyler is right that it can hurt the primary goal of
opening common programs if done badly. I think showing a separate
panel for the software center results would be enough to distinguish
both use cases and reduce the possible confusion.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Integrating Application Search & Install

[Tyler Brainerd]

On Wed, Apr 28, 2010 at 10:19 AM, Diego Moya  wrote:

> On 28 April 2010 10:50, Tyler Brainerd wrote:
> > If the goal of all this is to directly connect the user quickly with
> > their files and programs, then adding programs that are not currently
> > installed will only add clutter and messiness,
>
> The application menu has also the goal to let the user discover the
> applications available in the system.
>
> I like the idea of showing installable applications in the search
> results, but Tyler is right that it can hurt the primary goal of
> opening common programs if done badly. I think showing a separate
> panel for the software center results would be enough to distinguish
> both use cases and reduce the possible confusion.
>

Or at the very least, restrict the number of visible options, or have it
show options if there is no (or few) matches found on system. I still think,
either way, the discussion here is suggesting something which has
conflicting goals. Is it an app search or a file search? Is it currently
installed apps or installable apps? Its going to create a really mess. Lets
narrow the vision a bit, and then I think it will work.

In this note, we see in Windows a very clear application: The start menu is
meant as a hub of applications, so pressing it and typing searches
applications, not documents. Document names are often repetitive (I often
name documents simply numbers, and identify them based on location in a
folder) but application names make sense to search.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Finger Swipe Gadgets

[Mario Vukelic]

On Tue, 2010-04-27 at 22:45 +0300, Alex Lourie wrote:
> That is what I would call the fail-safe mechanism, and yet, I'd hope
> it would still work

Interesting conundrum, though:

Passwords work - as far as they do - because people use them quite
regularly and so they tend to remember them and to become good at typing
them, even random ones.

However, if nearly all of the time you log in by making faces, and just
have a password as a fallback when something goes wrong, chances are
that you can't remember it when the time comes that you need it.

In a corporate setting with forced password changes every x months, I
see the disaster of passwords stuck to the screen already.



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Finger Swipe Gadgets

[Alex Launi]

On Tue, Apr 27, 2010 at 3:26 PM, Alex Lourie  wrote:

> I'd be genuinely freaked if I couldn't login due to a broken camera :-)
>

Just to be fair, keyboards break more often than cameras do...


-- 
--Alex Launi
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Integrating Application Search & Install

[Diego Moya]

On 28 April 2010 12:47, Tyler Brainerd wrote:
>> either way, the discussion here is suggesting something which has
> conflicting goals. Is it an app search or a file search? Is it currently
> installed apps or installable apps? Its going to create a really mess. Lets
> narrow the vision a bit, and then I think it will work.

Does it matter? Google has trained users to type words into search
boxes and retrieve relevant information, no matter of what kind. If I
want to look for "photos" or "midi music" or "pay taxes" all those
results (files, installed aplications, applications in the
repositories) would help.

The goal for this system-level search box can be "show me everything
my Gnome/Ubuntu machine has to offer with respect to these keywords".
If you think of user goals instead of system features, this is what
makes more sense, and restricting the search to just one type of
element doesn't help. The only limitation in scope I would include is
limiting search to local information, don't go to the Ubuntu webpage
to gather results. But then I'm not even sure of that one.



> In this note, we see in Windows a very clear application: The start menu is
> meant as a hub of applications, so pressing it and typing searches
> applications, not documents. Document names are often repetitive (I often
> name documents simply numbers, and identify them based on location in a
> folder) but application names make sense to search.

If aiming for simplicity, I see how restricting search to just
applications can help. But when the user searches to retrieve
applications is because s/he don't know which application is the best
one to use for a given task, in which case it's highly valuable to
show all valid applications for that task, not just those installed.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Unexpected close functionality

[Jan Claeys]

Op dinsdag 27-04-2010 om 19:54 uur [tijdzone +0100], schreef Shane
Fagan:
> Adding more preferences is a last resort in my book. 

This is the sort of thing you want a preference for (if saving the last
state was the best solution, we wouldn't need one).

Maybe it could even be implemented by a plugin (not sure if plugins for
rhythmbox can add items to the preferences).


-- 
Jan Claeys


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Jan Claeys]

Op woensdag 28-04-2010 om 09:33 uur [tijdzone -0600], schreef Jeremy
Nickurak:
> This is an idea that's been debated alot, and in general, rejected, outside
> of macos circles. Decoupling the menu from the application window means you
> have to move your mouse from an application window, through an unrelated
> desktop region, up to a seperate region of the screen, which means it's not
> at all visually obvious that the menu at the top of the screen has
> *anything* to do with the application.

That's not an issue on netbooks.

> What about dialog windows that don't have menus, and don't get maximized? In
> that case, the top panel will just have a large empty space? 

I suggest you look at how that works now in the netbook remix/edition.


-- 
Jan Claeys


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Reducing Resistance to Change

[Jan Claeys]

Op woensdag 28-04-2010 om 08:40 uur [tijdzone +0200], schreef Mario
Vukelic:
> Maybe it would help to provide explanations, links to feedback options,
> etc. along with the changes. Currently users need to seek out the
> information on their own - and often the first thing they read is an
> inaccurate Slashdot summary that spawns a misguided discussion based on
> wrong assumptions. The information could be given during the upgrade
> process. E.g., I have installed apt-listchanges to email me news, but
> there scarcely are any, and certainly not about the design changes. Same
> if you use the GUI update-manager. 

I agree providing end-user upgrade notes might be a good thing, but of
course those won't be ready until near the release, as not all proposed
changes will end up in the release...


-- 
Jan Claeys


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Reducing Resistance to Change

[Andrew SB]

On Wed, Apr 28, 2010 at 2:40 AM, Mario Vukelic
 wrote:
> The experience is that as an interested
> user you are running the development version for months during the
> alphas with great expectations but nothing much to see UI-wise, and
> suddenly sweeping and often problematic changes land late in the cycle.
>
> This, I think, gives the impression that the design team is not really
> interested in user discussion/feedback. It also seems to me that this
> way of doing things gives very little time for users to get used to the
> changes, form a considered opinion and  give feedback. It also gives
> developers little time to consider the feedback or identify problems in
> other ways, and to implement appropriate iterations to fix them.
>
> To give a recent example, I was open to the question of having the
> window buttons on the left, but it's only now - a few days before
> release - that I feel I have used them enough to get somewhat used to
> them and really decide if I like them or not.
>
> On the other hand it's understandable, if you stop to think about it
> (often neglected on discussion boards), that the development cycle is
> actually used for development, and it's impossible to include some
> changes very early in the cycle for the simple fact that they are not
> done yet. There would also be the danger that earlier inclusion would
> just drag out the public discussions and with time let them deteriorate
> into senseless trolling even more.

I think that a lot of this has to do with simply working out project
management kinks in what is a fairly new team. My understanding is
that most of the folks on the Canonical design team don't come from a
distribution development background but from upstream application
development and non-Linux design backgrounds. And that's great! They
have the kind of experience that is going to push Ubuntu forward. But
it does raise issues with fitting their work into the our release
cycle.

I know that in the Karmic cycle there were some problems with the
design team respecting the various freezes, but from where I sit this
was much better in Lucid. Hopefully it will be even better going
forward as people fit into Ubuntu's development rhythm (dare I say
cadence?).

The application indicator and software center (although I suppose that
one fall under the rubric of the Foundations team) work seemed to land
fairly early in the cycle. I think we need to continue to embrace the
release early and often philosophy. Though this is much harder with
artwork. But do I think that it is important to remember that Lucid
saw an entire re-branding of our image, no small task and something
that more or less had to be rolled out all at once. Despite that, the
team still managed to get their work in on time for the UI freeze.

- Andrew SB

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Unexpected close functionality

[Marc Deslauriers]

On Thu, 2010-04-29 at 00:02 +0200, Jan Claeys wrote:
> Op dinsdag 27-04-2010 om 19:54 uur [tijdzone +0100], schreef Shane
> Fagan:
> > Adding more preferences is a last resort in my book. 
> 
> This is the sort of thing you want a preference for (if saving the last
> state was the best solution, we wouldn't need one).
> 

Actually, no. What you want to do is remember the last state _if_ the
app was automatically started with the session. If the app is started by
the user, then you forget the last state and display the window.

No need for a preference.

Marc.




___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Reducing Resistance to Change

[Mario Vukelic]

On Thu, 2010-04-29 at 00:32 +0200, Jan Claeys wrote:
> I agree providing end-user upgrade notes might be a good thing, but of
> course those won't be ready until near the release, as not all
> proposed changes will end up in the release... 

But as I mentioned, the facilities are in place to display information
*right at install* of a change. They just usually are not used. And I'm
not talking about complete release notes (which are published on the
website for each milestone and the release), but just a little note,
like "hey, we have made  for . You can read
more about it  and give feedback ".


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Jeremy Nickurak]

On Wed, Apr 28, 2010 at 16:14, Jan Claeys  wrote:

> That's not an issue on netbooks.
>
>
It's not an issue with *maximzed windows*. It's every bit as much as issue
for unmaximized windows on the netbook as it is for the desktop.

-- 
Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =-
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Reducing Resistance to Change

[Jeremy Nickurak]

Let's look at the "tooltip" dialog as an example of a place where people are
still "resisting change".
https://bugs.launchpad.net/indicator-application/+bug/527458?comments=all

I'd argue that what people are really concerned about is two things:


   1. A lack of consistency in the decision process
   2. Losing things in a change

On point 1: Looking at the tooltip bug in particular. The argument was made
that "menus don't have tooltips". But the *main* ubuntu menus, for
Applications, Places, and System, *all* have tooltips. As far as I know,
this was never addressed.

On point 2: People lost the ability to manage fine-grained information, or
in some cases, information at all. "Time to charge battery" is still
missing, as are many of the other things people brought up in that bug.
Which leads me to point #3: Communication

No real response to these questions came up. The closest we got to a
response was "the decision has been made and won't be changed for Lucid"
from Mark, which didn't actually address the particular criticisms that were
made. If the missing features were re-implemented elsewhere (especially
since some were accessability-related), or at least stated as not being
goals for Ubuntu, then people might be less resistant to it now. The lack of
communication on these points was more frustrating than anything. This is
one where the perception of an open dialog took a big hit, in my opinion.

-- 
Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =-
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp