Looks almost finished right now. I have still two (or more) questions: You start with 'Plasma callouts...' and talk later about callouts in general. As well in the appearance section and at 'content' the guidelines are about specific stuff. Is this intentional?

Secondly, we should think about the arbitrary numbers of 500ms and 2s. Perhaps it's better to have at least a bigger timeout (e.g. when text is more informative like 'KMail: You have 42 unread messages in account foo, and 17 in account bar.'). Another idea is to adopt the animation from notifications. It fades out slowly and you can stop it by moving the mouse. This provides sufficient feedback on what happens with a perfect control. And if you want to close it immediately just click the panel.

And last but not least: Is there a maximum size we want to advice? If I add the information on all tasks to the callout of the system load plasmoid it is still concise but not readable. I'd suggest to define a maximum of 5 lines, and a max width of 5% of screen width (the values are arbitrary again). Overlong information should get ellipsis. What I would expect in that situation is to have a direct interaction, that means I click on the tip (or any control to keep it consistent with to the former fade-out idea) and the form opens. How's about interactive elements?

Finally, most guidelines include an advice on capitalization. I think the header line has to be in title style, the lines in sentence style. What's about bullets? Disallowed from a design POV?

Comments from a dev, regarding what I read here: https://docs.google.com/a/davidedmundso ... yc4E/edit#

>Including the border, 15 pixels of padding horizontally, and 12 vertically.

This should not be in the spec. It's enforced by Tooltip anyway.

>The first line of text displays the name of of the plasmoid.
>The second line displays statuses

Use the words
"title" and "subtitle" here instead of first line and second line. It's the name of the properties in the tooltip developers use.

>All text within Plasma callout text must be left aligned (for LTR languages) and not indented.

Isn't really useful to devs; it's enforced at a code level (or if it's different now, should be)

This mockup https://i.imgur.com/xsrTKBR.jpg seems to go against the rule about having text left aligned.

david_edmundson wrote:Comments from a dev, regarding what I read here: https://docs.google.com/a/davidedmundso ... yc4E/edit#

>Including the border, 15 pixels of padding horizontally, and 12 vertically.

This should not be in the spec. It's enforced by Tooltip anyway.

>The first line of text displays the name of of the plasmoid.
>The second line displays statuses

Use the words
"title" and "subtitle" here instead of first line and second line. It's the name of the properties in the tooltip developers use.

>All text within Plasma callout text must be left aligned (for LTR languages) and not indented.

Isn't really useful to devs; it's enforced at a code level (or if it's different now, should be)

Thank you for that feedback!
Indeed we had decided at some point that we only put those things in the HIG which developers can actually influence.
On the other hand, though, if designers use the HIG to produce mockups, they may need information which would be irrelevant to developers implementing the mockups. If designers don't have that info and design e.g, a tooltip with different padding, the developer will have to tell them "Nah, padding is hard-coded" and this might lead to unnecessary irritation.
Maybe we'll have to find a way to mark any information that is only necessary for designers as such? In turn, of course, that would mean that we'd have to update the HIG in case the values in the code change. Or maybe we should just write "Always use the default values for padding"?

I included the line about padding because there are several tooltips that don't use a consistent padding, but I suppose those are bugs that I'll get on reporting. I'll edit the language, there are still some other parts that need to be polished in this regard. As for the task manager mockup, it was something I was playing with when I made the mockups, I'll fix it as soon as I get back to my desktop.

I'm still not sure what the font settings are, I've based my ideal font settings for callouts on what klipper uses, which several other callouts use as well. There are several tooltips now that set the font styles to something else, notably the network settings uses bolded font for both. I'll edit the document for capitalisation style.

The purpose for this design paper is for only the plasma callouts, or at least it is in my mind. I don't think I've ever seen a callout used in any native KDE application, or really any Qt app. For animations and time out, I've not mentioned it because there is the animation thread going on. Everything in the document should only apply to the callouts used for plasma.

For maximum size, all callouts should be limited vertically, I think that the klipper tooltip in use now is about the biggest a callout should be horizontally.

I would like it for callouts to use the notification animation. I couldn't comment on the timeouts, seems like the purview of surveys to see what others think on the timings.

Biggest things about the animation of callouts that I would like to see changed is tooltips closing faster when the mouse moves away from the panel, and not instantly opening another callout if one is already open. Right now if you mouse over notifications, you have to wait for the callout to appear, but if you move the mouse to battery settings without leaving the panel, the next callout opens immediately. But that's more of a usability issue than a design one.

enoop wrote:Biggest things about the animation of callouts that I would like to see changed is tooltips closing faster when the mouse moves away from the panel, and not instantly opening another callout if one is already open. Right now if you mouse over notifications, you have to wait for the callout to appear, but if you move the mouse to battery settings without leaving the panel, the next callout opens immediately. But that's more of a usability issue than a design one.

The HIGs were originally primarily intended for usability aspects. They do contain visual design aspects as well, but usability aspects should not be excluded from them.

enoop wrote:The purpose for this design paper is for only the plasma callouts, or at least it is in my mind. I don't think I've ever seen a callout used in any native KDE application, or really any Qt app.

Plasma is the sole software that applies a callout, yes. But if you write for a particular software it becomes rather a code of practice instead of a general guideline, IMHO.

enoop wrote:For maximum size, all callouts should be limited vertically, I think that the klipper tooltip in use now is about the biggest a callout should be horizontally.

Right now we have only "Design Plasma callouts to be a consistent height, but the callout height may be set on an individual basis so long as it conforms with all other guidelines." I read it as a callout might fill a third of the screen if necessary.

enoop wrote:I would like it for callouts to use the notification animation.... Biggest things about the animation of callouts that I would like to see changed is tooltips closing faster when the mouse moves away from the panel, and not instantly opening another callout if one is already open.

Fully agreed.

Right now we have only "Design Plasma callouts to be a consistent height, but the callout height may be set on an individual basis so long as it conforms with all other guidelines." I read it as a callout might fill a third of the screen if necessary.

Sorry, that was a typo. Standard callouts should follow the standard font settings and use a title and subtitle. Subtitle shouldn't be more than one line. So the height of all callouts should be the same. There may be some cases where the callout must be more than two lines, but it should be a very rare case.

I didn't include the animation behavior because that's not up to the applications, but rather behavior coded into all the tooltips. I'll add a line in the document to cover this.

What if I don't like tooltips? On 4.13.3, I have "helpful tips" disabled, because they are more often than not completly redundant and just pop there on mouse hover telling me over and over again "hey this icon that looks like Firefox is actually [drumroll] Firefox! ba-dum-tsch!". Same thing with notifications, networking, volume, battery and notifications. Yes, dear KDE, I can see from icons themselves if I'm connected and signal strength, approximate volume, approximate battery charge and number of notifications.

And here is the problem: as I disable those "helpful tips", the genuinely helpful tooltips are disabled as well. Things such as hover over taskbar entries showing me the thumbnails, clock showing me date and desktop pager showing applications running on different desktops.

daedaluz wrote:What if I don't like tooltips?

In general, callouts/tooltips (-> tip) have to be concise, helpful, and supplemental (cf. guideline on tool-tips). But I'd say the guideline for the tip itself shouldn't contain an advice to be dispensable what means you can hide it. Whether or not an application (e.g. Plasma) allows to disable all tips should be part of its description depending on use-cases. And in terms of Plasma it would be (is) rather confusing when you don't get a tip for an plasmoid (e.g. tray icon for Socket Sentry) instead of something less meaningful (e.g. 'Firefox #13 Post a reply...').

Anyway, isn't the draft ready to become part of the HIG (@enoop)? I'd place it below tool-tips.

Yeah, I'd say it's done. Let me edit the one mockup that doesn't follow the design if they are going into any official use. I don't have access to publish any of this myself as far as I'm aware, so whomever has that authority must do it.

enoop wrote:I don't have access to publish any of this myself as far as I'm aware, so whomever has that authority must do it.

The wiki is free to use with KDE identity.

enoop wrote:Yeah, I'd say it's done. Let me edit the one mockup that doesn't follow the design if they are going into any official use. I don't have access to publish any of this myself as far as I'm aware, so whomever has that authority must do it.

As Heiko said. Just go to https://techbase.kde.org/Projects/Usability/HIG to wherever it should be placed and then in the sidebar on the right click the bottom entry "OpenID / Identity login", click "Identity" and log in with the same credentials you use here in the forum. From then on, you can just edit any page.

Okay, I put it right below tooltips in the User-driven information section. Thanks for all the help in getting this done everyone, I hope this will improve plasma in some way in the future.

Many thanks for the guideline. I made a few editorial changes, but I'm not sure about the indention. Since bullets go down to the fourth level that could have any relevance. If not, please consider to move "Callouts should not contain any information..." and "Always follow standardised padding..." one level up.