Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Sergey "Shnatsel" Davidoff]

Aaaand the branch is merged!

But don't get too excited yet - the dock now shows the launcher not only if
it has any meaningful items, but if the D-bus interface is attached to the
launcher at all. Checks for badge and progressbar visibility are yet to be
implemented.

2013/3/20 Nishant George Agrwal 

>
> https://code.launchpad.net/~ricotz/plank/launcherentry-items
>
> The above link implements Plank's behaviour described in the following bug:
>
> https://bugs.launchpad.net/plank/+bug/1155790
>
> Here are two videos showing the changes off:
> http://youtu.be/G7TC9cdmuRE
> http://youtu.be/y7_R6glKQhE
>
> On Mon, Mar 18, 2013 at 1:00 AM, Nishant George Agrwal <
> nishantagrwal12...@gmail.com> wrote:
>
> So what's the final consensus on the matter, at least for Luna? Going
> ahead with the blueprint would mean:
>
> a) Biting the bullet and finally removing explicit minimize. Minimize will
> now be a technical detail transparent to the user. Close could mean
> different things, whatever makes the most sense for the app in question.
>
> b) Promoting minimize as the way to remove an application's window while
> still keeping the dock icon. This would also mean we assume that existing
> apps that implicitly minimize on close are those that would probably make
> sense not to have bound to one workspace.
>
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Nishant George Agrwal]

https://code.launchpad.net/~ricotz/plank/launcherentry-items

The above link implements Plank's behaviour described in the following 
bug:


https://bugs.launchpad.net/plank/+bug/1155790

Here are two videos showing the changes off:
http://youtu.be/G7TC9cdmuRE
http://youtu.be/y7_R6glKQhE

On Mon, Mar 18, 2013 at 1:00 AM, Nishant George Agrwal 
 wrote:
So what's the final consensus on the matter, at least for Luna? Going 
ahead with the blueprint would mean:


a) Biting the bullet and finally removing explicit minimize. Minimize 
will now be a technical detail transparent to the user. Close could 
mean different things, whatever makes the most sense for the app in 
question.


b) Promoting minimize as the way to remove an application's window 
while still keeping the dock icon. This would also mean we assume 
that existing apps that implicitly minimize on close are those that 
would probably make sense not to have bound to one workspace. 
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Nishant George Agrwal]

So what's the final consensus on the matter, at least for Luna? Going 
ahead with the blueprint would mean:


a) Biting the bullet and finally removing explicit minimize. Minimize 
will now be a technical detail transparent to the user. Close could 
mean different things, whatever makes the most sense for the app in 
question.


b) Promoting minimize as the way to remove an application's window 
while still keeping the dock icon. This would also mean we assume that 
existing apps that implicitly minimize on close are those that would 
probably make sense not to have bound to one workspace. 
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Sergey "Shnatsel" Davidoff]

2013/3/17 Nishant George Agrwal 

> On Sun, Mar 17, 2013 at 7:11 PM, Sergey Shnatsel Davidoff <
> ser...@elementaryos.org> wrote:
>
> So I believe it really depends on the app. If it has to be easier to
> access while it's running (e.g. Noise), it should display an icon in the
> dock.
>
>
> That still leaves the "not bound to a workspace" thing, which will need
> patches to both plank and Gala. Or are we ignoring that for the time being?
>

I don't think any Plank patches will be needed - tapping into minimize
function in Gala will probably be sufficient.

The easiest way to implement this is probably is via making any window
sticky (i.e. always shown on all workspaces) on minimizing it and restoring
its pristine state on maximizing. Gala already handles such windows
properly.

A cleaner solution would be adding checks for windows being minimized to
the places where checks for stickiness are already in place. It shouldn't
be too hard. The list of work items can be found at
https://blueprints.launchpad.net/gala/+spec/minimized-as-closed

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Nishant George Agrwal]

On Sun, Mar 17, 2013 at 7:11 PM, Sergey Shnatsel Davidoff 
 wrote:
So I believe it really depends on the app. If it has to be easier to 
access while it's running (e.g. Noise), it should display an icon in 
the dock. 


That still leaves the "not bound to a workspace" thing, which will need 
patches to both plank and Gala. Or are we ignoring that for the time 
being?
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Sergey "Shnatsel" Davidoff]

2013/3/17 Nishant Agrwal 

> Has this been uploaded to the daily repos? I have been playing around with
> it, and it appears the batch and progress bar appear even when no window
> for the app is opened, but this only works for launchers that are already
> pinned in the dock. Apologies if I have spoken too soon and the update has
> not yet landed.
>

Yes, and that's what has been implemented so far. The other bug report -
https://bugs.launchpad.net/plank/+bug/1155790 - is not so easy to fix
because Plank doesn't yet have a launcher state for such cases: the
launcher is neither pinned nor the app has any active windows.

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Sergey "Shnatsel" Davidoff]

2013/3/16 Daniel Fore 

> So, we should now have solved the problem of showing badges or
> progressbars when there are no windows open.
>

Only if the app is pinned to the dock. The other report still stands:
https://bugs.launchpad.net/plank/+bug/1155790


> So the remaining issue seems to be: If an app can be run in the
> background, should it's icon be present in the dock while it's running?
>
> Personally, I don't think that's entirely necessary. But I guess that
> depends on what your main use for the dock is.
>

Last time I checked the dock existed to make accessing a subset of
available applications faster, either by user preference (pinned apps) or
contextually (apps that are currently running, i.e. the ones the user is
interacting with at the moment).

Noise is a highly contextual app during playback. It should be easily
accessible so that you can pause playback or view song lyrics effortlessly.

Email, IM, VoIP and social network clients don't seem anywhere that
contextual to me. Each of them enables yet another means of communication;
having one running is like having your mobile phone turned on. I don't
think it's a good idea to display them all in the dock while you're online.*

So I believe it really depends on the app. If it has to be easier to access
while it's running (e.g. Noise), it should display an icon in the dock.
Otherwise the regular means of bringing it up are fine. If the user needs
to access them quickly every time, they'll probably pin it to the dock
anyway.
This also explains showing apps with new action items in the dock. E.g. for
email client, if you don't text people by yourself often, you don't need
its icon in the dock. And if you do, you already have it pinned. But you
should be able to access the IM client as effortlessly as possible if
somebody pinged you regardless of your regular usage pattern.
Can we get this polished and written down to HIG as a rule of thumb?

*IMO it would make much more sense to indicate and set the status for all
means of communication at once via Wingpanel indicator, as Maemo and Ubuntu
Maverick used to do until this dreadful "messaging menu" thing appeared.

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Nishant Agrwal]

Has this been uploaded to the daily repos? I have been playing around 
with it, and it appears the batch and progress bar appear even when no 
window for the app is opened, but this only works for launchers that 
are already pinned in the dock. Apologies if I have spoken too soon and 
the update has not yet landed.


On Sat, Mar 16, 2013 at 10:35 AM, Daniel Fore  
wrote:
Okay so it looks like Rico implemented one of those reports already. 
That was fast! So, we should now have solved the problem of showing 
badges or progressbars when there are no windows open.


So the remaining issue seems to be: If an app can be run in the 
background, should it's icon be present in the dock while it's 
running?


Personally, I don't think that's entirely necessary. But I guess that 
depends on what your main use for the dock is.


On Fri, Mar 15, 2013 at 4:16 PM, Sergey Shnatsel Davidoff 
 wrote:


Is there no way to both a. Have the window closed and b. show it's 
icon in the dock while c. Not having the app pinned?


It seems like a hack to open the window and then immediately 
minimize it. But I agree that having the icon available (when it 
makes sense) is a good thing. 


Even if this this is not currently programically possible, don't we 
have the means to make it so? Either through libplank or libunity 
or a combination of the two?




libunity's LauncherAPI doesn't provide a way to tell "show this 
launcher" or "hide this launcher", but we can make Plank show apps 
with a visible badge or progressbar regardless of their window 
visibility. I've filed that as a wishlist bug: 
https://bugs.launchpad.net/pantheon-dock/+bug/1155790


Without making any libunity notifications, we're fine as long as we 
don't need to show a dock icon without opening an app window, 
showing a badge or progressbar on it, or pinning it.


There's another bug that's a blocker for this use case, 
https://bugs.launchpad.net/pantheon-dock/+bug/1155789 but it doesn't 
look too tough.

 
Let's not try to derail discussion about what is a "real" service 
or what the HIG may or may not recommend about architecture. Lets 
try to keep to what exactly the problem we're having is and how we 
can solve that problem most cleanly. 




The problems brought up so far are: 


1) How do we handle hiding Noise
    * Minimize + 
https://blueprints.launchpad.net/gala/+spec/minimized-as-closed

    * Close to Slingshot/Indicator
    * Voodoo?
2) How do we handle running monitor-and-notify daemons, such as 
update-manager, email client, microblogging client, etc.
    * 
https://lists.launchpad.net/elementary-dev-community/msg02076.html

    * Any other suggestions?
3) What the hell does the speculation on front-end and back-end 
separation do in HIG
    * Find out what the original author intended, check facts and 
if they're true, add rationale to the article

    * Kill it with fire ASAP and investigate later

If trying to figure out and fix a controversial part of the HIG 
article counts as derailing the discussion, I can start a new tread 
about it, no problem. Shall I?


--
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Daniel Fore]

Okay so it looks like Rico implemented one of those reports already. 
That was fast! So, we should now have solved the problem of showing 
badges or progressbars when there are no windows open.


So the remaining issue seems to be: If an app can be run in the 
background, should it's icon be present in the dock while it's running?


Personally, I don't think that's entirely necessary. But I guess that 
depends on what your main use for the dock is.


On Fri, Mar 15, 2013 at 4:16 PM, Sergey Shnatsel Davidoff 
 wrote:


Is there no way to both a. Have the window closed and b. show it's 
icon in the dock while c. Not having the app pinned?


It seems like a hack to open the window and then immediately 
minimize it. But I agree that having the icon available (when it 
makes sense) is a good thing. 


Even if this this is not currently programically possible, don't we 
have the means to make it so? Either through libplank or libunity or 
a combination of the two?




libunity's LauncherAPI doesn't provide a way to tell "show this 
launcher" or "hide this launcher", but we can make Plank show apps 
with a visible badge or progressbar regardless of their window 
visibility. I've filed that as a wishlist bug: 
https://bugs.launchpad.net/pantheon-dock/+bug/1155790


Without making any libunity notifications, we're fine as long as we 
don't need to show a dock icon without opening an app window, showing 
a badge or progressbar on it, or pinning it.


There's another bug that's a blocker for this use case, 
https://bugs.launchpad.net/pantheon-dock/+bug/1155789 but it doesn't 
look too tough.

 
Let's not try to derail discussion about what is a "real" service or 
what the HIG may or may not recommend about architecture. Lets try 
to keep to what exactly the problem we're having is and how we can 
solve that problem most cleanly. 




The problems brought up so far are: 


1) How do we handle hiding Noise
    * Minimize + 
https://blueprints.launchpad.net/gala/+spec/minimized-as-closed

    * Close to Slingshot/Indicator
    * Voodoo?
2) How do we handle running monitor-and-notify daemons, such as 
update-manager, email client, microblogging client, etc.
    * 
https://lists.launchpad.net/elementary-dev-community/msg02076.html

    * Any other suggestions?
3) What the hell does the speculation on front-end and back-end 
separation do in HIG
    * Find out what the original author intended, check facts and 
if they're true, add rationale to the article

    * Kill it with fire ASAP and investigate later

If trying to figure out and fix a controversial part of the HIG 
article counts as derailing the discussion, I can start a new tread 
about it, no problem. Shall I?


--
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Sergey "Shnatsel" Davidoff]

> Is there no way to both a. Have the window closed and b. show it's icon in
> the dock while c. Not having the app pinned?
>
> It seems like a hack to open the window and then immediately minimize it.
> But I agree that having the icon available (when it makes sense) is a good
> thing.
>
> Even if this this is not currently programically possible, don't we have
> the means to make it so? Either through libplank or libunity or a
> combination of the two?
>

libunity's LauncherAPI doesn't provide a way to tell "show this launcher"
or "hide this launcher", but we can make Plank show apps with a visible
badge or progressbar regardless of their window visibility. I've filed that
as a wishlist bug: https://bugs.launchpad.net/pantheon-dock/+bug/1155790

Without making any libunity notifications, we're fine as long as we don't
need to show a dock icon *without* opening an app window, showing a badge
or progressbar on it, or pinning it.

There's another bug that's a blocker for this use case,
https://bugs.launchpad.net/pantheon-dock/+bug/1155789 but it doesn't look
too tough.


> Let's not try to derail discussion about what is a "real" service or what
> the HIG may or may not recommend about architecture. Lets try to keep to
> what exactly the problem we're having is and how we can solve that problem
> most cleanly.
>

The problems brought up so far are:

1) How do we handle hiding Noise
* Minimize +
https://blueprints.launchpad.net/gala/+spec/minimized-as-closed
* Close to Slingshot/Indicator
* Voodoo?
2) How do we handle running monitor-and-notify daemons, such as
update-manager, email client, microblogging client, etc.
* https://lists.launchpad.net/elementary-dev-community/msg02076.html
* Any other suggestions?
3) What the hell does the speculation on front-end and back-end separation
do in HIG
* Find out what the original author intended, check facts and if
they're true, add rationale to the article
* Kill it with fire ASAP and investigate later

If trying to figure out and fix a controversial part of the HIG article
counts as derailing the discussion, I can start a new tread about it, no
problem. Shall I?

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Daniel Foré]

Okay, so as far as I can tell, the deciding issue is about showing the dock 
icon?

Is there no way to both a. Have the window closed and b. show it's icon in the 
dock while c. Not having the app pinned?

It seems like a hack to open the window and then immediately minimize it. But I 
agree that having the icon available (when it makes sense) is a good thing. 

Even if this this is not currently programically possible, don't we have the 
means to make it so? Either through libplank or libunity or a combination of 
the two?

We already know that Canonical has this use case as well (with update manager). 
So I don't think they'd be opposed to a proper solution. 

Let's not try to derail discussion about what is a "real" service or what the 
HIG may or may not recommend about architecture. Lets try to keep to what 
exactly the problem we're having is and how we can solve that problem most 
cleanly. 

Best Regards,
Daniel Foré

El mar 15, 2013, a las 9:56 a.m., Victor  escribió:

> 
> 
> On Fri, Mar 15, 2013 at 6:07 AM, Sergey Shnatsel Davidoff 
>  wrote:
>>> The big question is, "should background apps minimize or close their 
>>> window?"
>> 
>> AFAIK it's a purely technical issue that's ultimately up to Gala devs, so I 
>> can't see the point of writing it down to the HIG or discussing it here. 
>> 
>> IMO the UX-related question is "when should background apps show their icon 
>> in the dock, and if should they do that at all?". 
>> 
>> It seemed to me that Noise should be easily accessible from the dock while 
>> it plays music, so that the user can pause playback or switch to the next 
>> track easily, regardless of the presence of media keys, which are still 
>> uncommon around here. Also, turns out many people don't discover media keys 
>> even when they are present - keyboards have so many keys...
>> 
>> This is why I pushed for minimizing Noise during playback when running in 
>> Pantheon. I also pushed for making it exhibit shell-native behavior, e.g. 
>> hide the window instead of minimizing it when running in Unity, but I'm not 
>> sure if that was implemented.
> 
> That was fully implemented. Noise minimizes its window instead of hiding it 
> in Pantheon and GNOME Shell, and simply hides the window for the rest of 
> shells. It uses the following GSettings key to decide for which shells it 
> should minimize the window: 
> /org/pantheon/noise/settings/minimize-while-playing-shells (See my other 
> comment).
> 
>>  
>>> I'm inclined to think that close is the cleaner solution here when we're 
>>> talking about making closing workspaces on Gala work properly, making 
>>> "opening" (re-opening technically) these apps work as expected, etc. Think 
>>> about it this way: How many apps does a user maybe want to be running in 
>>> the background on start-up 24/7? Here's a few background apps I know that I 
>>> have running on my Phone:
>>> 
>>> Twitter
>>> Facebook
>>> Email
>>> Messages
>>> ESPN (gotta know when Barça is playing)
>>> Music
>>> Calls
>>> Mint (I get alerts if I go over-budget)
>>> Fitocracy
>>> 
>>> Does it make sense to have all these windows minimized to my 1st workspace 
>>> every time I log in since they all (in at least some way) need to be 
>>> running in order to work properly? I just don't think that makes sense from 
>>> a window management perspective.
>> 
>> I'll reply with a quote from the very same HIG page:
>> 
>>> If the app performs repeat background tasks (such as checking for new 
>>> mail), the background tasks should be handled by a separate daemon.
>> 
>> All the apps from your list except Music perform some background tasks 
>> repeatedly, so they fall into this "background daemon" category. More 
>> specifically, they wait for some event and notify you when it happens. Of 
>> course it's counter-productive to make them all clutter the dock at all 
>> times. 
>> 
>> However, showing a dock badge with the number of action items in the app is 
>> an important means of notifying the user about the event because this way 
>> the dock provides a persistent overview of remaining action items. Dock 
>> badges are complementary to showing a notification but they're also 
>> important because the user is not always willing to react to a notification 
>> immediately and notification backlogs are far too cluttered to be useful.
>> 
>> The way I see it, these "background daemons" should only display an icon in 
>> the dock when the daemon has some new action items. Although the definition 
>> of "new" is a bit vague here - looking at how some people never get the 
>> unread mail count in their inbox to zero, I doubt it's a good idea to show 
>> an email client inon in the dock with the badge "243" all the time. Maybe 
>> it's better to only show the icon when the number of unread threads 
>> increases or display the number of unread emails since you last checked the 
>> inbox instead of the actual count of unread threads. But this is a topic for 
>> another discussion.
>> 
>>

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Victor]

On Fri, Mar 15, 2013 at 6:07 AM, Sergey Shnatsel Davidoff 
 wrote:
The big question is, "should background apps minimize or close their 
window?"




AFAIK it's a purely technical issue that's ultimately up to Gala 
devs, so I can't see the point of writing it down to the HIG or 
discussing it here. 

IMO the UX-related question is "when should background apps show 
their icon in the dock, and if should they do that at all?". 

It seemed to me that Noise should be easily accessible from the dock 
while it plays music, so that the user can pause playback or switch 
to the next track easily, regardless of the presence of media keys, 
which are still uncommon around here. Also, turns out many people 
don't discover media keys even when they are present - keyboards have 
so many keys...


This is why I pushed for minimizing Noise during playback when 
running in Pantheon. I also pushed for making it exhibit shell-native 
behavior, e.g. hide the window instead of minimizing it when running 
in Unity, but I'm not sure if that was implemented.




That was fully implemented. Noise minimizes its window instead of 
hiding it in Pantheon and GNOME Shell, and simply hides the window for 
the rest of shells. It uses the following GSettings key to decide for 
which shells it should minimize the window: 
/org/pantheon/noise/settings/minimize-while-playing-shells (See my 
other comment).



 
I'm inclined to think that close is the cleaner solution here when 
we're talking about making closing workspaces on Gala work properly, 
making "opening" (re-opening technically) these apps work as 
expected, etc. Think about it this way: How many apps does a user 
maybe want to be running in the background on start-up 24/7? Here's 
a few background apps I know that I have running on my Phone:


Twitter
Facebook
Email
Messages
ESPN (gotta know when Barça is playing)
Music
Calls
Mint (I get alerts if I go over-budget)
Fitocracy

Does it make sense to have all these windows minimized to my 1st 
workspace every time I log in since they all (in at least some way) 
need to be running in order to work properly? I just don't think 
that makes sense from a window management perspective.




I'll reply with a quote from the very same HIG page:

If the app performs repeat background tasks (such as checking for 
new mail), the background tasks should be handled by a separate 
daemon.


All the apps from your list except Music perform some background 
tasks repeatedly, so they fall into this "background daemon" 
category. More specifically, they wait for some event and notify you 
when it happens. Of course it's counter-productive to make them all 
clutter the dock at all times. 

However, showing a dock badge with the number of action items in the 
app is an important means of notifying the user about the event 
because this way the dock provides a persistent overview of remaining 
action items. Dock badges are complementary to showing a notification 
but they're also important because the user is not always willing to 
react to a notification immediately and notification backlogs are far 
too cluttered to be useful.


The way I see it, these "background daemons" should only display an 
icon in the dock when the daemon has some new action items. Although 
the definition of "new" is a bit vague here - looking at how some 
people never get the unread mail count in their inbox to zero, I 
doubt it's a good idea to show an email client inon in the dock with 
the badge "243" all the time. Maybe it's better to only show the icon 
when the number of unread threads increases or display the number of 
unread emails since you last checked the inbox instead of the actual 
count of unread threads. But this is a topic for another discussion.


And regarding that quote, I have a bone to pick:

If the app performs repeat background tasks (such as checking for 
new mail), the background tasks should be handled by a separate 
daemon.
Not only the Human Interface Guidelines advice on the matters of 
software architecture, they also provide no rationale for doing so. 
It's as ridiculous as an interior designer writing "and by the way, 
only build houses on this type of foundation" in a book on interior 
design. I mean, what can interior designers possibly know about 
foundations? And why do they even care?




Couldn't agree more. Sometimes you only need to hide the window from 
the world. Otherwise, for big apps like music players, the users would 
have to wait for the entire UI to be created again fetching information 
from the daemon (or somewhere else) in order to resume working. This is 
not ideal, considering you only save a couple of megabytes of memory 
used by the UI, and everybody hates startup times; this would only 
bring unresponsiveness. This type of information doesn't belong to the 
HIG.




--
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-co

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Nishant Agrwal]

Okay, good. Now having said that, you would prefer to have Noise 
minimize if the music was playing instead of closing (from the UI 
standpoint this would mean that the dock icon is still visible) simple 
because the quick access to the icon would be needed to pause the music 
or select a new song. Is that right? Designers, what do you think of 
this user experience?


On Fri, Mar 15, 2013 at 8:14 PM, Sergey Shnatsel Davidoff 
 wrote:

2013/3/15 Nishant Agrwal 
Shnatsel, assuming your blueprint implemented, would the following 
be a correct summation of your desired behaviour? I am assuming that 
none of the mentioned apps are pinned to the dock.


- user logs in, and several daemons start up and check for events.
- when the daemons detect an event of interest, like a new email, 
message, news, etc, a notification bubble is shown and, if 
appropriate, an icon in the dock with a batch appears. I would think 
this would be implemented as a window that instantly minimizes?
- Because gala is to treat minimized windows as closed, this 
applications window would be shown in neither the window or the 
workspace overviews. The dock, however, would show this window in 
all workspaces. Clicking on the icon would bring up the application 
window on the current workspace.
- When the user closes this window, the window actually closes 
(disappears from the dock).


This would be what I would expect of the "background tasks" category.



Yes! The implementation may vary but this is exactly the user 
experience I have in mind.

 
--
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Sergey "Shnatsel" Davidoff]

2013/3/15 Nishant Agrwal 

> Shnatsel, assuming your blueprint implemented, would the following be a
> correct summation of your desired behaviour? I am assuming that none of the
> mentioned apps are pinned to the dock.
>
> - user logs in, and several daemons start up and check for events.
> - when the daemons detect an event of interest, like a new email, message,
> news, etc, a notification bubble is shown and, if appropriate, an icon in
> the dock with a batch appears. I would think this would be implemented as a
> window that instantly minimizes?
> - Because gala is to treat minimized windows as closed, this applications
> window would be shown in neither the window or the workspace overviews. The
> dock, however, would show this window in all workspaces. Clicking on the
> icon would bring up the application window on the current workspace.
> - When the user closes this window, the window actually closes (disappears
> from the dock).
>
> This would be what I would expect of the "background tasks" category.
>

Yes! The implementation may vary but this is exactly the user experience I
have in mind.

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Nishant Agrwal]

Shnatsel, assuming your blueprint implemented, would the following be a 
correct summation of your desired behaviour? I am assuming that none of 
the mentioned apps are pinned to the dock.


- user logs in, and several daemons start up and check for events.
- when the daemons detect an event of interest, like a new email, 
message, news, etc, a notification bubble is shown and, if appropriate, 
an icon in the dock with a batch appears. I would think this would be 
implemented as a window that instantly minimizes?
- Because gala is to treat minimized windows as closed, this 
applications window would be shown in neither the window or the 
workspace overviews. The dock, however, would show this window in all 
workspaces. Clicking on the icon would bring up the application window 
on the current workspace.
- When the user closes this window, the window actually closes 
(disappears from the dock).


This would be what I would expect of the "background tasks" category.

On Fri, Mar 15, 2013 at 5:37 PM, Sergey Shnatsel Davidoff 
 wrote:
The big question is, "should background apps minimize or close their 
window?"




AFAIK it's a purely technical issue that's ultimately up to Gala 
devs, so I can't see the point of writing it down to the HIG or 
discussing it here. 

IMO the UX-related question is "when should background apps show 
their icon in the dock, and if should they do that at all?". 

It seemed to me that Noise should be easily accessible from the dock 
while it plays music, so that the user can pause playback or switch 
to the next track easily, regardless of the presence of media keys, 
which are still uncommon around here. Also, turns out many people 
don't discover media keys even when they are present - keyboards have 
so many keys...


This is why I pushed for minimizing Noise during playback when 
running in Pantheon. I also pushed for making it exhibit shell-native 
behavior, e.g. hide the window instead of minimizing it when running 
in Unity, but I'm not sure if that was implemented.

 
I'm inclined to think that close is the cleaner solution here when 
we're talking about making closing workspaces on Gala work properly, 
making "opening" (re-opening technically) these apps work as 
expected, etc. Think about it this way: How many apps does a user 
maybe want to be running in the background on start-up 24/7? Here's 
a few background apps I know that I have running on my Phone:


Twitter
Facebook
Email
Messages
ESPN (gotta know when Barça is playing)
Music
Calls
Mint (I get alerts if I go over-budget)
Fitocracy

Does it make sense to have all these windows minimized to my 1st 
workspace every time I log in since they all (in at least some way) 
need to be running in order to work properly? I just don't think 
that makes sense from a window management perspective.




I'll reply with a quote from the very same HIG page:

If the app performs repeat background tasks (such as checking for 
new mail), the background tasks should be handled by a separate 
daemon.


All the apps from your list except Music perform some background 
tasks repeatedly, so they fall into this "background daemon" 
category. More specifically, they wait for some event and notify you 
when it happens. Of course it's counter-productive to make them all 
clutter the dock at all times. 

However, showing a dock badge with the number of action items in the 
app is an important means of notifying the user about the event 
because this way the dock provides a persistent overview of remaining 
action items. Dock badges are complementary to showing a notification 
but they're also important because the user is not always willing to 
react to a notification immediately and notification backlogs are far 
too cluttered to be useful.


The way I see it, these "background daemons" should only display an 
icon in the dock when the daemon has some new action items. Although 
the definition of "new" is a bit vague here - looking at how some 
people never get the unread mail count in their inbox to zero, I 
doubt it's a good idea to show an email client inon in the dock with 
the badge "243" all the time. Maybe it's better to only show the icon 
when the number of unread threads increases or display the number of 
unread emails since you last checked the inbox instead of the actual 
count of unread threads. But this is a topic for another discussion.


And regarding that quote, I have a bone to pick:

If the app performs repeat background tasks (such as checking for 
new mail), the background tasks should be handled by a separate 
daemon.
Not only the Human Interface Guidelines advice on the matters of 
software architecture, they also provide no rationale for doing so. 
It's as ridiculous as an interior designer writing "and by the way, 
only build houses on this type of foundation" in a book on interior 
design. I mean, what can interior designers possibly know about 
foundations? And why do they even care?


--
Sergey "Shnatsel" Davidoff

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Sergey "Shnatsel" Davidoff]

>
> The big question is, "should background apps minimize or close their
> window?"
>

AFAIK it's a purely technical issue that's ultimately up to Gala devs, so I
can't see the point of writing it down to the HIG or discussing it here.

IMO the UX-related question is "when should background apps show their icon
in the dock, and if should they do that at all?".

It seemed to me that Noise should be easily accessible from the dock while
it plays music, so that the user can pause playback or switch to the next
track easily, regardless of the presence of media keys, which are still
uncommon around here. Also, turns out many people don't discover media keys
even when they are present - keyboards have so many keys...

This is why I pushed for minimizing Noise during playback when running in
Pantheon. I also pushed for making it exhibit shell-native behavior, e.g.
hide the window instead of minimizing it when running in Unity, but I'm not
sure if that was implemented.


> I'm inclined to think that close is the cleaner solution here when we're
> talking about making closing workspaces on Gala work properly, making
> "opening" (re-opening technically) these apps work as expected, etc. Think
> about it this way: How many apps does a user maybe want to be running in
> the background on start-up 24/7? Here's a few background apps I know that I
> have running on my Phone:
>
> Twitter
> Facebook
> Email
> Messages
> ESPN (gotta know when Barça is playing)
> Music
> Calls
> Mint (I get alerts if I go over-budget)
> Fitocracy
>
> Does it make sense to have all these windows minimized to my 1st workspace
> every time I log in since they all (in at least some way) need to be
> running in order to work properly? I just don't think that makes sense from
> a window management perspective.
>

I'll reply with a quote from the very same HIG page:

If the app performs repeat background tasks (such as checking for new
> mail), the background tasks should be handled by a separate daemon.


All the apps from your list except Music perform some background tasks
repeatedly, so they fall into this "background daemon" category. More
specifically, they wait for some event and notify you when it happens. Of
course it's counter-productive to make them all clutter the dock at all
times.

However, showing a dock badge with the number of action items in the app is
an important means of notifying the user about the event because this way
the dock provides a persistent overview of remaining action items. Dock
badges are complementary to showing a notification but they're also
important because the user is not always willing to react to a notification
immediately and notification backlogs are far too cluttered to be useful.

The way I see it, these "background daemons" should only display an icon in
the dock when the daemon has some new action items. Although the definition
of "new" is a bit vague here - looking at how some people never get the
unread mail count in their inbox to zero, I doubt it's a good idea to show
an email client inon in the dock with the badge "243" all the time. Maybe
it's better to only show the icon when the number of unread threads
increases or display the number of unread emails since you last checked the
inbox instead of the actual count of unread threads. But this is a topic
for another discussion.

And regarding that quote, I have a bone to pick:

If the app performs repeat background tasks (such as checking for new
> mail), the background tasks should be handled by a separate daemon.


Not only the *Human Interface* Guidelines advice on the matters of software
architecture, they also provide no rationale for doing so. It's as
ridiculous as an interior designer writing "and by the way, only build
houses on this type of foundation" in a book on interior design. I mean,
what can interior designers possibly know about foundations? And why do
they even care?

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Daniel Foré]

Yea, I mean personally I have media keys on my keyboard, but I would assume
(though I'm not sure) that system media controls are going to be important
in the tablet workflow.

touché with indicators-never-launch-apps. But realistically they do launch
apps already :p I think more accurately, indicators don't exist for the
purpose of launching apps. They just happen to also include that ability.
But that's another story I think.

The big question is, "should background apps minimize or close their
window?"

I'm inclined to think that close is the cleaner solution here when we're
talking about making closing workspaces on Gala work properly, making
"opening" (re-opening technically) these apps work as expected, etc. Think
about it this way: How many apps does a user maybe want to be running in
the background on start-up 24/7? Here's a few background apps I know that I
have running on my Phone:

Twitter
Facebook
Email
Messages
ESPN (gotta know when Barça is playing)
Music
Calls
Mint (I get alerts if I go over-budget)
Fitocracy

Does it make sense to have all these windows minimized to my 1st workspace
every time I log in since they all (in at least some way) need to be
running in order to work properly? I just don't think that makes sense from
a window management perspective.



On Wed, Mar 13, 2013 at 1:15 PM, Craig  wrote:

> As a data point, I never use the sound indicator for anything besides
> adjusting volume. I can't put my finger on why, and I've certainly tried;
> however, I always find myself going back to the application to control the
> application. Again, this is just my data point. :)
>
>
> On Wed, Mar 13, 2013 at 10:32 AM, Sergey "Shnatsel" Davidoff <
> ser...@elementaryos.org> wrote:
>
>> 2013/3/13 Daniel Foré 
>>
>>> Yea except that you can already access it quickly through the sound
>>> indicator.
>>>
>>
>> That requires more clicks and much higher precision of cursor navigation.
>> Fitts' law in action.
>>
>> Besides, I doubt that opening music player through that indicator
>> sufficiently discoverable. I bet many people won't discover option even if
>> they open the indicator, and they probably won't do that in the first place.
>>
>> Also, what happened to the "Indicators Never Launch Apps" mantra?
>> Nevermind, don't bother answering this one, I'm
>> content with just seeing it gone.
>>
>> --
>> Sergey "Shnatsel" Davidoff
>> OS architect @ elementary
>>
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to : elementary-dev-community@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>


-- 
Best Regards,

Daniel Foré

elementaryos.org
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Craig]

As a data point, I never use the sound indicator for anything besides
adjusting volume. I can't put my finger on why, and I've certainly tried;
however, I always find myself going back to the application to control the
application. Again, this is just my data point. :)


On Wed, Mar 13, 2013 at 10:32 AM, Sergey "Shnatsel" Davidoff <
ser...@elementaryos.org> wrote:

> 2013/3/13 Daniel Foré 
>
>> Yea except that you can already access it quickly through the sound
>> indicator.
>>
>
> That requires more clicks and much higher precision of cursor navigation.
> Fitts' law in action.
>
> Besides, I doubt that opening music player through that indicator
> sufficiently discoverable. I bet many people won't discover option even if
> they open the indicator, and they probably won't do that in the first place.
>
> Also, what happened to the "Indicators Never Launch Apps" mantra?
> Nevermind, don't bother answering this one, I'm
> content with just seeing it gone.
>
> --
> Sergey "Shnatsel" Davidoff
> OS architect @ elementary
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Sergey "Shnatsel" Davidoff]

2013/3/13 Daniel Foré 

> Yea except that you can already access it quickly through the sound
> indicator.
>

That requires more clicks and much higher precision of cursor navigation.
Fitts' law in action.

Besides, I doubt that opening music player through that indicator
sufficiently discoverable. I bet many people won't discover option even if
they open the indicator, and they probably won't do that in the first place.

Also, what happened to the "Indicators Never Launch Apps" mantra?
Nevermind, don't bother answering this one, I'm
content with just seeing it gone.

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Daniel Foré]

Yea except that you can already access it quickly through the sound indicator. 
If you really want to access it quickly on the dock, you can just pin the app.

Best Regards,
Daniel Foré

El mar 13, 2013, a las 7:10 a.m., "Sergey \"Shnatsel\" Davidoff" 
 escribió:

> The reason I pushed for minimizing in Noise instead of closing to make its 
> icon remain in the dock so that it can be accessed easily as long as the 
> music keeps playing.
> 
> 2013/3/13 Daniel Foré 
>> I grew with Nishant that Noise should in fact close its window rather than 
>> minimize it. Having it bound to a workspace is definitely not what I expect 
>> to happen.
> 
> Exactly! IMO this is true for any minimized app. That's why I filed a 
> blueprint about treating minimized apps as closed, so that they're not bound 
> to any particular workspace. 
> 
> Parts of that have already landed in Gala, see linked bug reports. It 
> shouldn't be hard to complete it if the design teams gives the green light.
> 
> -- 
> Sergey "Shnatsel" Davidoff
> OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Daniel Foré]

Yes

Best Regards,
Daniel Foré

El mar 12, 2013, a las 10:54 p.m., Nishant Agrwal 
 escribió:

> Daniel, so if I understand you right, you are supportive of the hide/unhide 
> behaviour as opposed to the current minimize solution?
> 
> On Wed, Mar 13, 2013 at 2:13 AM, Daniel Foré  wrote:
>> I grew with Nishant that Noise should in fact close its window rather than 
>> minimize it. Having it bound to a workspace is definitely not what I expect 
>> to happen.
>> 
>> But like Nishant, I don't interact with the music player window very often. 
>> In fact, on my phone I use the system player controls and rarely ever 
>> actually open the music app unless I'm in the mood for a specific song.
>> 
>> Best Regards,
>> Daniel Foré
>> 
>> El mar 12, 2013, a las 8:45 a.m., Cody Garver  
>> escribió:
>> 
>>> It's just weird to me that closing Noise doesn't have the same result as 
>>> closing everything else. I understand what it's going for, I think I just 
>>> don't have the workflow it expects or something. Let's see what design team 
>>> says about your feedback.
>>> 
>>> 
>>> On Tue, Mar 12, 2013 at 10:36 AM, Nishant Agrwal 
>>>  wrote:
 Could you elaborate on why you didn't like it? 
 
 Here's my rationale for proposing the closing/hiding behaviour:
 I think the way most people use music players is - start the player, 
 choose the song, and close the window. Basically, the player window's only 
 functionality is to allow choosing the song and managing playlists, etc. 
 So throughout the application's use, the window remains largely unused. 
 Also, because Pantheon supports a multiple workspace layout, our users 
 might be in a different workspace from where they started the music player 
 when they need to bring up the window again (perhaps to change a song). 
 Clicking on the Noise icon on the dock would take them back to the other 
 workspace, when all they wanted to do was to quickly select a song and get 
 back to their work. Hiding and un-hiding the window could make the window 
 show on the current workspace. 
 
 Of course this behaviour could be implemented for all apps while sticking 
 to minimize by changing the dock's behaviour as Daniel had suggested some 
 time back, but this would not integrate well with other DEs. This also 
 raises the general design question: Should applications intended to be run 
 mostly in the background (think torrent clients, instant messaging) be 
 bound to a particular workspace?
 
 Just my two cents.
 
 On Tue, Mar 12, 2013 at 8:35 PM, Cody Garver  wrote:
> After using it a while, I decided I don't like this behavior.
> 
> 
> On Tue, Mar 12, 2013 at 8:53 AM, Nishant Agrwal 
>  wrote:
>> I was reading this page of the HIG:
>> http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-tasks
>> 
>> I couldn't help noticing that the page specifically mentions the 
>> expected behaviour from a music player, yet Noise minimizing instead of 
>> hiding the window completely. Just thought I'd point it out. Thoughts?
>> 
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to : elementary-dev-community@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> -- 
> Cody Garver
 
 --
 Mailing list: https://launchpad.net/~elementary-dev-community
 Post to : elementary-dev-community@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~elementary-dev-community
 More help   : https://help.launchpad.net/ListHelp
>>> 
>>> 
>>> 
>>> -- 
>>> Cody Garver
>>> -- 
>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>> Post to : elementary-dev-community@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>> More help   : https://help.launchpad.net/ListHelp
> -- 
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Sergey "Shnatsel" Davidoff]

The reason I pushed for minimizing in Noise instead of closing to make its
icon remain in the dock so that it can be accessed easily as long as the
music keeps playing.

2013/3/13 Daniel Foré 

> I grew with Nishant that Noise should in fact close its window rather than
> minimize it. Having it bound to a workspace is definitely not what I expect
> to happen.
>

Exactly! IMO this is true for any minimized app. That's why I filed a
blueprint about treating minimized apps as
closed,
so that they're not bound to any particular workspace.

Parts of that have already landed in Gala, see linked bug reports. It
shouldn't be hard to complete it if the design teams gives the green light.

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Nishant Agrwal]

Thank you Victor. That really solves things in my case. Still, I feel 
this is something we should discuss, perhaps after the Luna cycle.


On Wed, Mar 13, 2013 at 12:24 PM, Victor  
wrote:

FWIW...

$ sudo apt-get install dconf-tools
$ dconf write 
/org/pantheon/noise/settings/minimize-while-playing-shells "['']"


On Tue, Mar 12, 2013 at 7:53 AM, Nishant Agrwal 
 wrote:

I was reading this page of the HIG:
http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-tasks

I couldn't help noticing that the page specifically mentions the 
expected behaviour from a music player, yet Noise minimizing instead 
of hiding the window completely. Just thought I'd point it out. 
Thoughts?
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Victor]

FWIW...

$ sudo apt-get install dconf-tools
$ dconf write /org/pantheon/noise/settings/minimize-while-playing-shells "['']"

On Tue, Mar 12, 2013 at 7:53 AM, Nishant Agrwal  
wrote:
I was reading this page of the HIG:
http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-tasks

I couldn't help noticing that the page specifically mentions the expected 
behaviour from a music player, yet Noise minimizing instead of hiding the 
window completely. Just thought I'd point it out. Thoughts?-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Nishant Agrwal]

Daniel, so if I understand you right, you are supportive of the 
hide/unhide behaviour as opposed to the current minimize solution?


On Wed, Mar 13, 2013 at 2:13 AM, Daniel Foré  
wrote:
I grew with Nishant that Noise should in fact close its window rather 
than minimize it. Having it bound to a workspace is definitely not 
what I expect to happen.


But like Nishant, I don't interact with the music player window very 
often. In fact, on my phone I use the system player controls and 
rarely ever actually open the music app unless I'm in the mood for a 
specific song.


Best Regards,
Daniel Foré

El mar 12, 2013, a las 8:45 a.m., Cody Garver  
escribió:


It's just weird to me that closing Noise doesn't have the same 
result as closing everything else. I understand what it's going for, 
I think I just don't have the workflow it expects or something. 
Let's see what design team says about your feedback.



On Tue, Mar 12, 2013 at 10:36 AM, Nishant Agrwal 
 wrote:

Could you elaborate on why you didn't like it? 

Here's my rationale for proposing the closing/hiding behaviour:
I think the way most people use music players is - start the 
player, choose the song, and close the window. Basically, the 
player window's only functionality is to allow choosing the song 
and managing playlists, etc. So throughout the application's use, 
the window remains largely unused. Also, because Pantheon supports 
a multiple workspace layout, our users might be in a different 
workspace from where they started the music player when they need 
to bring up the window again (perhaps to change a song). Clicking 
on the Noise icon on the dock would take them back to the other 
workspace, when all they wanted to do was to quickly select a song 
and get back to their work. Hiding and un-hiding the window could 
make the window show on the current workspace. 


Of course this behaviour could be implemented for all apps while 
sticking to minimize by changing the dock's behaviour as Daniel had 
suggested some time back, but this would not integrate well with 
other DEs. This also raises the general design question: Should 
applications intended to be run mostly in the background (think 
torrent clients, instant messaging) be bound to a particular 
workspace?


Just my two cents.

On Tue, Mar 12, 2013 at 8:35 PM, Cody Garver 
 wrote:

After using it a while, I decided I don't like this behavior.


On Tue, Mar 12, 2013 at 8:53 AM, Nishant Agrwal 
 wrote:

I was reading this page of the HIG:
http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-tasks

I couldn't help noticing that the page specifically mentions the 
expected behaviour from a music player, yet Noise minimizing 
instead of hiding the window completely. Just thought I'd point 
it out. Thoughts?


--
Mailing list: https://launchpad.net/~elementary-dev-community
Post to     : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp






--
Cody Garver



--
Mailing list: https://launchpad.net/~elementary-dev-community
Post to     : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp






--
Cody Garver


‘5’
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Daniel Foré]

I grew with Nishant that Noise should in fact close its window rather than 
minimize it. Having it bound to a workspace is definitely not what I expect to 
happen.

But like Nishant, I don't interact with the music player window very often. In 
fact, on my phone I use the system player controls and rarely ever actually 
open the music app unless I'm in the mood for a specific song.

Best Regards,
Daniel Foré

El mar 12, 2013, a las 8:45 a.m., Cody Garver  escribió:

> It's just weird to me that closing Noise doesn't have the same result as 
> closing everything else. I understand what it's going for, I think I just 
> don't have the workflow it expects or something. Let's see what design team 
> says about your feedback.
> 
> 
> On Tue, Mar 12, 2013 at 10:36 AM, Nishant Agrwal 
>  wrote:
>> Could you elaborate on why you didn't like it? 
>> 
>> Here's my rationale for proposing the closing/hiding behaviour:
>> I think the way most people use music players is - start the player, choose 
>> the song, and close the window. Basically, the player window's only 
>> functionality is to allow choosing the song and managing playlists, etc. So 
>> throughout the application's use, the window remains largely unused. Also, 
>> because Pantheon supports a multiple workspace layout, our users might be in 
>> a different workspace from where they started the music player when they 
>> need to bring up the window again (perhaps to change a song). Clicking on 
>> the Noise icon on the dock would take them back to the other workspace, when 
>> all they wanted to do was to quickly select a song and get back to their 
>> work. Hiding and un-hiding the window could make the window show on the 
>> current workspace. 
>> 
>> Of course this behaviour could be implemented for all apps while sticking to 
>> minimize by changing the dock's behaviour as Daniel had suggested some time 
>> back, but this would not integrate well with other DEs. This also raises the 
>> general design question: Should applications intended to be run mostly in 
>> the background (think torrent clients, instant messaging) be bound to a 
>> particular workspace?
>> 
>> Just my two cents.
>> 
>> On Tue, Mar 12, 2013 at 8:35 PM, Cody Garver  wrote:
>>> After using it a while, I decided I don't like this behavior.
>>> 
>>> 
>>> On Tue, Mar 12, 2013 at 8:53 AM, Nishant Agrwal 
>>>  wrote:
 I was reading this page of the HIG:
 http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-tasks
 
 I couldn't help noticing that the page specifically mentions the expected 
 behaviour from a music player, yet Noise minimizing instead of hiding the 
 window completely. Just thought I'd point it out. Thoughts?
 
 --
 Mailing list: https://launchpad.net/~elementary-dev-community
 Post to : elementary-dev-community@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~elementary-dev-community
 More help   : https://help.launchpad.net/ListHelp
>>> 
>>> 
>>> 
>>> -- 
>>> Cody Garver
>> 
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to : elementary-dev-community@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> -- 
> Cody Garver
> -- 
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Cody Garver]

It's just weird to me that closing Noise doesn't have the same result as
closing everything else. I understand what it's going for, I think I just
don't have the workflow it expects or something. Let's see what design team
says about your feedback.


On Tue, Mar 12, 2013 at 10:36 AM, Nishant Agrwal <
nishantagrwal12...@gmail.com> wrote:

> Could you elaborate on why you didn't like it?
>
> Here's my rationale for proposing the closing/hiding behaviour:
> I think the way most people use music players is - start the player,
> choose the song, and close the window. Basically, the player window's only
> functionality is to allow choosing the song and managing playlists, etc. So
> throughout the application's use, the window remains largely unused. Also,
> because Pantheon supports a multiple workspace layout, our users might be
> in a different workspace from where they started the music player when they
> need to bring up the window again (perhaps to change a song). Clicking on
> the Noise icon on the dock would take them back to the other workspace,
> when all they wanted to do was to quickly select a song and get back to
> their work. Hiding and un-hiding the window could make the window show on
> the current workspace.
>
> Of course this behaviour could be implemented for all apps while sticking
> to minimize by changing the dock's behaviour as Daniel had suggested some
> time back, but this would not integrate well with other DEs. This also
> raises the general design question: Should applications intended to be run
> mostly in the background (think torrent clients, instant messaging) be
> bound to a particular workspace?
>
> Just my two cents.
>
> On Tue, Mar 12, 2013 at 8:35 PM, Cody Garver 
> wrote:
>
> After using it a while, I decided I don't like this behavior.
>
>
> On Tue, Mar 12, 2013 at 8:53 AM, Nishant Agrwal <
> nishantagrwal12...@gmail.com> wrote:
>
>> I was reading this page of the HIG:
>>
>> http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-tasks
>>
>> I couldn't help noticing that the page specifically mentions the expected
>> behaviour from a music player, yet Noise minimizing instead of hiding the
>> window completely. Just thought I'd point it out. Thoughts?
>>
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to : elementary-dev-community@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Cody Garver
>
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Cody Garver
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Nishant Agrwal]

Could you elaborate on why you didn't like it? 

Here's my rationale for proposing the closing/hiding behaviour:
I think the way most people use music players is - start the player, 
choose the song, and close the window. Basically, the player window's 
only functionality is to allow choosing the song and managing 
playlists, etc. So throughout the application's use, the window remains 
largely unused. Also, because Pantheon supports a multiple workspace 
layout, our users might be in a different workspace from where they 
started the music player when they need to bring up the window again 
(perhaps to change a song). Clicking on the Noise icon on the dock 
would take them back to the other workspace, when all they wanted to do 
was to quickly select a song and get back to their work. Hiding and 
un-hiding the window could make the window show on the current 
workspace. 


Of course this behaviour could be implemented for all apps while 
sticking to minimize by changing the dock's behaviour as Daniel had 
suggested some time back, but this would not integrate well with other 
DEs. This also raises the general design question: Should applications 
intended to be run mostly in the background (think torrent clients, 
instant messaging) be bound to a particular workspace?


Just my two cents.

On Tue, Mar 12, 2013 at 8:35 PM, Cody Garver  
wrote:

After using it a while, I decided I don't like this behavior.


On Tue, Mar 12, 2013 at 8:53 AM, Nishant Agrwal 
 wrote:

I was reading this page of the HIG:
http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-tasks

I couldn't help noticing that the page specifically mentions the 
expected behaviour from a music player, yet Noise minimizing instead 
of hiding the window completely. Just thought I'd point it out. 
Thoughts?


--
Mailing list: https://launchpad.net/~elementary-dev-community
Post to     : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp






--
Cody Garver
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Noise doesn't comply to HIG

[Cody Garver]

After using it a while, I decided I don't like this behavior.


On Tue, Mar 12, 2013 at 8:53 AM, Nishant Agrwal <
nishantagrwal12...@gmail.com> wrote:

> I was reading this page of the HIG:
>
> http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-tasks
>
> I couldn't help noticing that the page specifically mentions the expected
> behaviour from a music player, yet Noise minimizing instead of hiding the
> window completely. Just thought I'd point it out. Thoughts?
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Cody Garver
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp