Potential input for the Extra Mile project

[A.B. Ole]

Hi Aurélien,

I didn't have time before, but hereby my reply to your comments :)


On 20 November 2012 15:49, Aurélien Gâteau <agateau at kde.org> wrote:

> Le jeudi 15 novembre 2012 23:44:12 A.B. Ole a écrit :
>
> First of all, thank you very much for taking the time to write all this!
> I am commenting your suggestions inline below.
>
> > I've tried to categorize them, as I found some common factors.
> > *
> > Alignment issues:*
> > * in the Quicklaunch widget: particularly when the launcher names are not
> > shown, the icons seem to have strong preference for horizontal alignment.
> > When making the widget bigger, the icons scale with it. That's good,
> except
> > for that, when I want vertical alignment, I can only do that with small
> > icons. It seems that this issue occurs specifically when showing launcher
> > names.
> > Suggestion for fixing : add an option to switch between horizontal and
> > vertical alignment of icons, of alternatively: fix the number of
> > rows/columns
> > * Again the quicklaunch widget : If launcher names are shown, and the
> icons
> > are aligned vertically, the quiklaunch widget can be made so narrow that
> > the lables don't fit in. This looks very strange.
>
> I think those two problems would be fixed if the labels were constrained
> to the
> panel width and wrapped or cut if they did not fit. This would help with
> layouting.
>
> Indeed this would help solving the second issue (the one with the labels
not fitting in). The first issue is a bigger problem for me personally, as
I prefer having the launchers without labels (that's when the first issue
occurs), so I'm forced to have them in a horizontal shape.


> > * Activity bar widget: same strange preference for horizontal alignment
> of
> > the activity buttons as the icons in the quicklaunch widget.
>
> Agreed. This widget seems to completely ignore panel orientation.
>
> I think this is related to the first issue with the quicklauncher that I
mentioned. It seems very similar to me. If this is caused by shared
KDE/plasma code: all reshapable widgets may have this problem, and
therefore all benifit from having a 'horizontal alignment preference' vs.
'vertical alignment preference' switch option. If, however, this behaviour
is caused by the individual widgets...I hope the widget maintainers read
this post :-)


> > * ACtivity bar widget : the widget can be made smaller than the buttons.
> > This looks very weird. I think this is the same problem as with the
> > quicklaunch widget, as described above.
>
> Agreed.
>
> > * Panel adjustment: adjusting the width and position of the panel is very
> > complicated and confusing. Also in the "more settings" drop-down menu:
> what
> > do these panel alignment options exactly do? I understand they are
> > mathematically very elegant ways to describe how the panel positioning
> > works, but it seems unnecessarily complicated. 'Average users' won't
> > understand. Only having it adjustable at the left and right ends would be
> > good enough - perhaps add a button to have the panel always in the middle
> > of the screen. That's already more than most people will use (probably
> they
> > will have the panel bar filling the entire width of the screen).
>
> I agree with those, but I don't think it qualify as extra mile bugs
> because it
> is not something which is "simple to fix". That does not mean it should
> not be
> fixed, but it requires one to dedicate a significant amount of time to
> come up
> with a more elegant design, get it approved and implement it.
>
> I agree with that, unfortunately it's beyond the Extra Mile limit of
'simple to fix'. Hope that someone who knows how to rewrite this reads
this.


> > *Slowly responding interface:*
> > * The system tray elegantly allows the user to hide certain items. That's
> > really good. But, when scolling through the hidden items by mouse (after
> > clicking on the up-arrow that reveals them), the highlighting of the item
> > is slower than the mouse, if I move the pointer over the list of hidden
> > tray items rapidly.
>
> Probably easy to fix, might already be fixed in the upcoming version. I
> need to
> check.
>
> > * The application launcher : it has this very convenient 'switch tabs on
> > hover' option. However, if I want to reach the 'leave' section rapidly,
> the
> > tab switching follows the mouse too slowly. Please add an option to let
> the
> > user decide on how slowly the tabs switch on mouse hovering. Zero delay
> by
> > default feels best to me, but that may be a matter of taste.
> > * THe same holds for moving the mouse over the taskbar while 'window
> > previews' are shown. When moving the mouse from one window to an other
> the
> > previews want to follow, but they are too slow.
> > * same issue when moving the mouse over the widgets in the 'add widget'
> > thing.
>
> I personally don't like the idea of adding options to fine-tune behaviors
> like
> that. I'd rather adjust the existing delays to "feel right", out of the
> box.
> That is harder, but better for the user experience.
>

I totally agree. Making things feel right out of the box is the way
forward: average users won't feel the urge to change things, so you don't
have to offer 'configuration dials' or things like that on the human
interface. But, regarding the behaviour of the application launcher and the
window previews: I figure they can benefit from the same fix you mentioned
for the system tray hidden items.


> > * Pop-ups :*
> > * pop-ups appear when the 'add widget' thing is active, and they block
> the
> > user interface. If, for example, the mouse is on the most left widget, a
> > large popup appears, covering the search bar. If the mouse is on the
> second
> > left widget the 'categories button' is blocked.
> >
> > * The popups in the 'add widget' thing are not necessary in the first
> > place: they display the same description as the widgets do themselves,
> and
> > they mention something about the author and the type of license. Most
> users
> > don't care about that, and if they want to know these things
> nevertheless,
> > I would suggest putting them in the configuration dialog box of each
> > widget.
>
> Agreed, they are annoying and would benefit from being clickable (for
> example
> to open the widget website or copy the author email)
>
> Why not just leave these popups out entirely, and have all the relevant
info (+ hyperlink to the authors homepage / email) only appear in the
"settings" dialog box. A convenient place would be a "sub-dialog" like the
General, Keyboard Shortcut or Share- sub-dialogs. Make an additional
sub-dialog, call it for example 'Background Info', and store all this info
in that sub-dialog. This makes it easy to find for people who are
interested in these things (...which are the same kind of people who are
willing to look around until they find it anyway), but at the same time
this keeps it out of the way for people who do NOT want to read these info.
Also, this avoids the pop-ups from popping up, and thereby does not hamper
the funcitoning of this widget as it is now.


> > *Layout :*
> > * the colour of the blue glow (of active windows): adjusting the colour
> of
> > turning the glowing off is hard to find. Also, the glow colour is unique.
> > It should be linked to a colour in the theme colours.
>
> Agreed.
>
> > * in Dolphin, the icon in the Information panel is huge compared to
> > anything else in the Dolphin window. What does this icon add for the user
> > in the first place?
>
> I guess it is mostly there as a placeholder: it makes sense to have an icon
> like this when previewing images or videos. If the icon were not there, the
> content would jump up and down based on whether a file is selected or not.
>
> I understand what you mean. Couldn't this be solved by reserving an amount
of space determined by the size of the Dolphin window and/or the screen
resolution? This space could be entirely filled in by a previewer, but also
by a smaller icon to which a maximum size is defined. So if the icon is
smaller than the reserved space, just centre it, or so.


> One thing which would be easy to try is to just use empty space if nothing
> is
> there. I am not sure if it would look nice, but that should be easy to try
> out.
>
> I guess it's mostly a matter of 'fiddling around' until it looks good.


> > * the 'multiple tabs' layout of the application launcher seems somewhat
> > oldfashioned. Combining it into 1 thing is convenient. Look, for example,
> > at Linux Mint. THeir menu is one of their most appreciated items...with
> > good reason
>
> That is not an extra mile bug: what you are asking there requires rewriting
> the whole launcher. I am not saying you are wrong, but it's out of the
> scope
> of extra miles.
>

OK, that's fair enough


> > *Miscellaneous:*
> > * battery indicator : show how many minutes of battery time I have left,
> or
> > at least have the option to do so.
>
> While this sounds sensible, it is surprisingly difficult to get right, and
> subject of many flamewars. You can find some of them on the plasma-devel
> mailing
> list. Latest one started from there:
> http://mail.kde.org/pipermail/plasma-devel/2012-June/020063.html
>
> ...well...it's a sensitive topic, apparently. Without hinting on how
accurate the indicator should be: any indication is good. Hopefully
accurate, but if not perfectly adequate: average users as I defined in my
previous email, probably won't verify the indicator by stop watch.
Order-of-magnitude is convenient.


> > * the "add widgets" thing, normally put above the bottom panel, has an
> > inconvenient layout. Making the 'widget objects'smaller would make them
> > more easy to oversee. Now it's difficult.
>
> Another complicated topic. I am no fan of the "add widgets" thing either,
> but
> changing it is again out of scope of extra mile bugs.
>
> OK, I understand.


> > *Unpleasant one to fix :*
> > * when hitting the F1 button of the 'Help'button in any dialog box, I
> > expect relevant information, not a link to the KDE manual/ plasma widgets
> > section. I know this is a lot of work, but in the 21st century 'average
> > users' expect this anyway. Also, after all dialog boxes have been
> updated,
> > maintaining the consistency is relatively little work.
>
> There is an embarrassing problem with this: we actually do not have manual
> pages for Plasma applet, so no real content to show :/
> The best thing we can do there is probably not to open any documentation
> when
> one presses F1.


That may be hard to digets for the average user...he/she just expects help.


> There is already no Help button in Plasma applet configuration
> dialogs, so it would be consistent to have no Help shortcut as well.
>
> That certainly is consistent :) I do believe having 'Help content' in the
configuration dialogs would be good. It probably is easy to fix, and
therefore does qualify as an Extra Mile bug, but it's just a lot of work.

>
>
> Where to go from there? The best thing to do is to file bugs for your
> ideas on
> bugs.kde.org. As I said, a few of your ideas do not qualify as
> extra-mile, so
> they should not be marked as such, but you can still file bugs for them.
> To learn more about bugs.kde.org, you can read:
> http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla
>
> OK, thanks. YOu indicated some of my comments as not-extra-mile, so for
these ideas I'll file a regular bug in the near future.

Thanks for your comments. I'm happy to contribute this way (I know it's the
easy way - but I'm not very much of a programmer)

Regards,

Alrik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-testing/attachments/20121126/5537932e/attachment.html>