<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 23, 2015 at 5:46 PM, Xen <span dir="ltr"><<a href="mailto:list@xenhideout.nl" target="_blank">list@xenhideout.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <br>
    <div>
      
      <pre style="white-space:pre-wrap;color:rgb(0,0,0);font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px"><span class="">>><i> On June 23, 2015, 10:40 a.m., Kai Uwe Broulik wrote:
</i>>><i> > I actually really like it, perhaps we should make KDialog passive popup not set an icon by default now
</i>>><i> 
</i></span><span class="">>><i> Philipp A. wrote:
</i>>><i>     i also like the no-icon no-space version. why add something that just takes up unnecessary space and has no informational value?
</i>
> I prefer the no-icon version as well. I don't think the visual inconsistency is a problem. On the
> contrary, I think reducing the uniformity may somewhat reduce strain when scanning notifications
> since they become more individualized landmarks in the stack. It also makes the presence of icons in
> the notifications that do sport them feel more purposeful, making it more likely to pay attention to
> icons and getting something out of it instead of getting trained to ignore them and look at the only
> reliably disambiguifying content (the text). This way, you look straight at the text - the only
> meaningful content, without having to skip over the icon.

> - Eike</span></pre>
      <br>
      If I may be allowed to add some opinion here, being just a
      bystander...<br>
      <br>
      Being trained to ignore a default icon is more like an automatism
      and it serves in means of recognition. That doesn't mean you have
      to pay visual attention to the other icons or that visual
      (conscious) attention would be a good thing. Ideally it becomes a
      subconscious process anyway.<br>
      <br>
      Getting a differing spacing (left-side indentation) for no-icon
      and do-icon introduces more fatigue. That means perusing the
      notification stack becomes a more tiring thing. The informational
      value of the icons or of having no icon doesn't add anything much
      in terms of "information intake" and most of the notifications...<br>
      <br>
      Sorry to say so, but my own personal KDE experience has been that
      there are way many notifications and most of them don't serve a
      good purpose and clearing the notifcation stack becomes a chore.
      E.g. Clementine (I don't use Amarok) sends a
      play-event/notification to the stack on every item played. It is
      pretty senseless to be notified about new songs in a way that long
      surpasses what the song is doing. A temporary song, a temporary
      item, would better have a temporary notification (such as the
      on-screen popup that Amarok does or used to do and that Clementine
      perhaps does also (don't remember)). Helpful would be a vertical
      stack displayed on-screen where each item has a timer before it
      disappears and clears the stack (or reduces the stack size
      (vertically, the number of items present on the screen) and
      perhaps in conjunction with a permanent history thing. I feel a
      large amount of time (relatively speaking) is being dedicated by
      the user in clearing that stack. It is one of my gripes in KDE.<br></div></div></blockquote><div><br></div><div>This exact issue is addressed in Plasma 5 - Clementine, Amarok and Spotify by default get only</div><div>one single notification popup which is not stored in history. So if you quickly switch songs and/or</div><div>change states of the playback, there will always be only one popup with always the latest data</div><div>(because the previous data is obsolete by then anyway). Any other application can be added</div><div>to the list by adding it to a config file (not ideal but also not meant to be a public configuration</div><div>at this point).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      Applications that don't set an icon is also something that ..how
      to say. It could be dissuaded and not designed around. I think it
      would be a bad thing if your direction would be about "not trying
      to get a consistent look" but perhaps that is irrelevant as each
      author can decide by him/herself. I just feel a common default
      icon would be a boon in terms of looks and the reducement of
      visual fatigue as the user only has to look in a default location
      for all text (visually space/oriented) and ease of
      repetition/recognition is a good thing.<br></div></div></blockquote><div><br></div><div>The ease of repetition and recognition was what I had in mind with the first patch, yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      Lately visual interface designers have for mostly political
      reasons I believe done away with the "everything would preferably
      be in a default location" concept that has long been the way of
      doing menus etcetera. If you can find something blindly, that
      increases the speed of your operation of the machine. But recently
      (e.g. in Windows start menu etc.) (and the Unity Dock, etc.) <i>searching</i>
      has become a more apt way to do things. In Windows it is so bad
      that without searching, you can't even find anything. E.g. the
      "configuration screen" of Windows 7 and 8 (you can even barely
      find it in Windows 10) has been reorganized to the extent that it
      is very fatigueing to read any of the text (because it is all very
      long) and the only way to get anywhere is usually to search.<br>
      <br>
      By contrast the KDE menu (Kicker?) is still very doable although
      it is not as fast as the Windows XP menu used to be. Searching is
      still often an apt way to get somewhere (especially if you don't
      know where to look) but at least the results are fast and
      pleasantly oriented. A scrolling side-to-side menu is not really a
      good way to get anywhere (repeatedly) because every click is a
      separate action that requires wait-time before you can do the next
      move. In contrast, a cascading/unfolding menu is very rapid
      because it is like "one motion" to get anywhere.<br>
      <br>
      But search always requires mental attention which introduces
      fatigue and lowers the speed. Searching is never a trained thing.
      Which is why, of course, you can add stuff to Favourites. But
      there's not enough space in the favourites to include everything
      you want. Which means you get back to clicking on desktop-icons, a
      thing the menu tries to avoid or supersede!! Personally I know no
      way to organize my favourite applications and I resort to desktop
      icons and direct krunner activity.<br>
      <br>
      But, to recap, familiarity is important, predictability is
      important, efficiency is really all that matters, and
      informational value of icons is not really all that important (as
      long as they look good and are recognisable) (and distinguisable)
      as it is a subconscious process anyway. So having a default icon
      does not really take away from the recognition of the other icons,
      but I deally I would ensure that very few default icons remain
      anyway. The default icon could also better be round or square.
      Anyway, these are just my thoughts.<br></div></div></blockquote><div><br></div><div>Thanks for sharing your thoughts. I tend to agree with you but I'll leave the final word on this</div><div>particular issue to our Visual Design Group.</div></div><div><br></div><div>Cheers</div>-- <br><div class="gmail_signature"><div><span style="color:rgb(102,102,102)">Martin Klapetek | KDE Developer</span></div></div>
</div></div>