KDE Developer
|
Without having read the entire topic, I just wanted to throw my few cents in:
A major annoyance with Plasma's tooltip in my opinion is that they don't disappear when you start typing on the keyboard or press a shortcut. For example: I have a Chrome window open, and happen to hover the Kickoff menu (I have my panel at the top). The Kickoff tooltip appears. Now I press Ctrl+T to open a new tab and start typing the address. The tooltip covers the address bar making it impossible to see what I'm typing, especially since they're so huge. Most of the traditional tooltips would disappear then. |
Registered Member
|
Good point! Plasma tooltips covering things they shouldn't be covering are indeed annoying. |
Registered Member
|
I would recommend to have a different name for those kind of user-driven information: Callout is the common name.
I worry about the use in KDE software, we have to avoid a mix of standard tool-tips and callouts. On the other hand it could make sense to use callouts in apps with simple command pattern when the information to show in the tip is not concise and rather relevant than supplemental. From the usability POV I would rather go with a different UI than introducing a control that is known from web design (where it make sense because tool-tips belong to controls, and callouts are associated with page elements). So I would step back for a moment and ask why we use callouts in Plasma at all (instead of standard tips). |
Registered Member
|
I find the callout to be more helpful in identifying what is spawning the callout as opposed to the tooltip. The panel can be quite dense in information at times, there can be many system tray entries packed in a small space for example. The callout ties the information being displayed to the item displaying it better by pointing right at the spawning item. I agree that a mix of tooltips and callouts could look unpolished, but I don't think any KDE app uses callouts to my knowledge. Making plasma use them wouldn't look inconsistent IMO.
@Saabhero I agree, it was just something I was playing around with, the window preview is centered, so I thought it would look weird if the text wasn't. I'll fix it. @kbroulik They also don't disappear if you click the widget that shows them. There are still some issues with tooltips that prevent them from getting out of the way when they aren't needed. I think the task manager is a big problem with this too. The timings that tooltips appear and disappear are wonky. Tooltips should be as clear and concise as possible, and get out of the way when they are not needed. |
Registered Member
|
The progress on fleshing this out has been wonderful. Great work!
Are we getting to the point where we can start putting the guidelines together into a cohesive set for review? |
Registered Member
|
Yeah, are there any examples that I could follow to make sure the recommendation matches up? I can type something up and every one here can pick it apart for any problems.
|
Registered Member
|
Feel free to just type something up. For the moment the general guideline structure is: Purpose blah blah blah Guidance
It doesn't have to be long or wordy, in fact it's better if it's not. Pictures and examples are also great. Just go for it. |
Registered Member
|
Yup, I agree. It's often easier to just start writing and then optimizing later than to try to know everything up-front. |
Registered Member
|
Is anyone working on this? If not, I would start the draft. |
Registered Member
|
We had originally put enoop in charge of this, but since he seems to be a bit unsure of where to start, I'm sure it would be great if you two could work on it together, given that you have the most experience in writing KDE HIGs here |
Registered Member
|
Sorry, I've been on vacation for the last few days. I'll try to get a rough outline posted in the next day.
|
Registered Member
|
Alright, I wrote out a rough outline of my guide lines. Does anyone know the exact size and font settings used by plasma tooltips? Be sure to give me your feedback on anything. This is my first time writing anything like this.
https://docs.google.com/document/d/1iha ... sp=sharing |
Registered Member
|
I added a few comments to the document (just drafts, the wording should get improved). Basically, the name of this control should be 'callout' to describe it independently from Plasma (BTW: Perhaps plasma should be capitalized.) The common structure of the HIG pages is Purpose, Guidelines, Examples, and Implementation with 'Is this the right control' (when to use and when not), Behavior (how to implement), and Appearance (how to design) below guidelines.
About the integration into the HIG: I would suggest to place it at 'User Assistance' below 'User-driven information'. PS: For discussion: If a callout relates to a vertical item, like a controlbar that is attached to a screen side, shouldn't it be designed differently? |
Registered Member
|
Great work so far! I also agree with most of Heiko's edits.
I'd just remove most/all of the "should"s. Even though HIGs are guidelines, not rules, they sound more confident without "should" all over the place. I don't see much reason for designing Callouts for Plasmoids on vertical panels in a different way at the moment, but maybe I've missed something. |
Registered Member
|
i've accepted the changes made and removed the "shoulds" and changed tooltips to callouts. I've left references to plasma though for now as my intention for this design was to change the plasma tooltips, leaving application tooltips design to others, as for now they seem to be separate entities. I agree that callouts don't need to be resigned for vertical elements. All callouts should be the same height, it helps keep them from drawing attention. For examples I'll use the mockups I've made.
|
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan