- User Since
- Sep 15 2015, 6:32 PM (136 w, 18 h)
Thu, Apr 5
- So do we have context menus in Kirigami / QQC2 right now or not?
- And what about spin boxes? Is there actually a QQC2 for those? Apart from that technical question: I would not recommend them on mobile, their buttons are too small for touch.
- Is there a traditional tooltip in QQC2?
- Last time I talked to people, there was no treeview in QQC2. Is there one now?
Mar 22 2018
- Drawers are not mobile-only. Most desktop apps will probably opt for sidebars instead of drawers on desktop, but if you want to allow users to show some UI elements only on demand, a drawer can make sense even on desktop. They just work slightly differently (on desktop the drawer stays open until you close it manually), but that should be described within the page. It's still the same pattern
- As far as I know, Kirigami does not have a menubar and so far doesn't plan to have one, so that would be QWidget-only
- Plasma does have context menus
- Currently Kirigami uses toolbars only on desktop (on mobile they are floating action buttons). This might change in the future, but for the time being, toolbars are desktop-only
Feb 26 2018
light weight -> lightweight
look in reStructuredText like this -> looks like this in reStructured Text
Feb 21 2018
Now it has the same icon as the handle for the Context Drawer. On the one hand that's good because they do very similar things, but on the other hand if an app uses both, it could be a bit confusing
Feb 9 2018
Feb 6 2018
Jan 19 2018
This is a clear improvement from my perspective, and I don't see it introducing any usability issues.
I think that when at the bottom, having the combobox is okay because it's not too prominent. The only problem I see is that it means that changing a combobox changes the content above it, which is not usually expected behavior for a combobox.
Jan 14 2018
Dunno why I only noticed it now, but of course then this is not the right place to fix it. Sorry for the noise.
My only concern would be that in the mouseover state the contrast between the grip and groove is quite low. This could make the two difficult to distinguish, especially for color blind users. Could perhaps the contrast in terms of brightness be increased a bit?
Dec 30 2017
This layout makes more sense to me as well overall. The only thing that I find a bit strange is that the summary now looks a bit like a headline, especially given that the application name is in the toolbar instead of the content area. I'm wondering if we should move the name and icon into the content area.
Dec 21 2017
Dec 20 2017
With that many available algorithms, the combobox solution makes more sense to me as well.
@James In fact, this is exactly what we've promised people in 2014 ( https://sessellift.wordpress.com/2014/04/02/choose-your-own-experience-this-time-its-for-real/ ), and what we've been getting the technology ready for since then.
The Plasma team is against shipping the other L&Fs directly with Plasma because that would mean they'd have to maintain them in case the original author loses interest, but getting them with a one-click install via store.kde.org is the idea.
Nov 29 2017
This proposal unfortunately was not selected as a goal for KDE as a whole to focus on.
That does not mean that we should not work on it, of course. As the discussion here shows, there is a relevant subset of the community who is interested in this topic, and I think we should work on it anyway, even if the whole of KDE is not focusing on it.
These are two different things, and both relevant. Yes, things should work "out of the box". Yes, things should ideally be self-explanatory.
Games (regardless of platform) and many mobile apps and OSes have shown, however, that it's often not possible for everything to be self-explanatory. Or if you make it so, you end up with a "chatty UI" that annoys users once they've figured it out.
Nov 28 2017
Nov 22 2017
Nov 18 2017
I can confirm that the dropdowns work on mobile now, thanks for fixing this!
Nov 14 2017
Nov 12 2017
Why don't we do this the way Firefox does it: Have a menu entry that puts the whole UI in config mode.
That works far better then trying to make each individual config feature discoverable.
Nov 6 2017
much better version control. eg at the moment it's next to impossible to create and discuss a draft
Nov 3 2017
Oct 20 2017
Oct 18 2017
So, what do we do with this proposal and https://phabricator.kde.org/T7116 now? They are so similar that it really makes little sense from my perspective to keep them separated.
Can @ngraham and @neofytosk maybe see how to proceed with merging them into one which contains all aspects of both?
Otherwise votes would end up split between the two, effectively reducing the chance for either of them to be selected.
Oct 15 2017
@laysrodrigues Yes, that is exactly what this proposal is about :)
Inlcude reminder of duty to attend AGM or find proxy
@hook We saw you subsrcibed to this task. Would you be interested in looking into this? That would help us a lot!
Oct 14 2017
I am definitely all for getting design more involved, but I feel that this proposal needs to be more detailed and concrete before I'm ready to sign it.
Oct 9 2017
I'm happy that there is a lot of discussion happening here, but maybe the discussion about annotations in Okular is getting a bit too much into detail for this point in the process.
So let's maybe summarize it for now as "There are potentially some issues with compatibility of Okular annotations, so if this goal gets selected, this could be one of the things we look into, together with academic / research users.
Oct 6 2017
Oct 5 2017
This is hugely important, from an accessibility, internationalization as well as usability perspective. That's why I'd be happy to help with UX design and testing.
Oct 4 2017
Oct 3 2017
Oct 2 2017
Colors are more @jensreuterberg 's thing.
Sep 25 2017
This is a goal which (hopefully) pretty much everyone in KDE can rally behind (otherwise our Vision, Mission and Strategy would not reflect the community's).
Sep 21 2017
Yes, I totally agree.
Application Dashboard in Plasma initially shows recent applications by default (which makes a ton of sense!).
Don't worry: After many years working as a usability consultant and UX designer, I know that I have to distinguish between my own needs and user needs.
Sep 13 2017
Why don't we simply copy the Firefox dialog?
Firefox has a big userbase and with the default settings, the vast majority of users will see this dialog at some point. Therefore if their wording was problematic, it's very likely someone would have flamed them for it.
So I'd consider their dialog "real-world tested".
Sep 6 2017
Aug 31 2017
Aug 30 2017
Aug 29 2017
Aug 21 2017
@bshah The "Halium Unifies Mobile Linux" section of the article "Plasma rocks Akademy"  seems to cover the things you mentioned above.
Do you feel that what should be said about Halium has now been said, or are there more things that should be promoted about Halium?
Aug 9 2017
Aug 8 2017
Aug 7 2017
The answer to that is share.kde.org (our Nextcloud installation).
The cleanest way to do that is to ask sysadmin to create a shared folder there along with an Identity group that gets access to it and contains everyone in this project.
Jul 26 2017
Jul 11 2017
Since Piwik can already track if people come to our articles from social networks, I'm not sure if URL shorteners provide us with any additional information. They don't track things like number of followers or number of likes or reshares anyway.
Jul 5 2017
Final edit from my side:
Final tiny nitpick:
Jun 13 2017
Sounds really good!
May 13 2017
May 3 2017
Okay, to be honest: I don't fully understand what you guys are talking about ;)
- Is the mouse-driven workflow mentioned here new in Plasma 5.10, or is it so hidden in 5.9 that I simply cannot find it?
- Where do these shortcuts come from, where do they already exist?
Apr 13 2017
It definitely should not be an option. Either it's better, then it goes in, or it isn't, then it doesn't.
Who has complained about this? Can we see the reports?
If it's most likely to be decided only on the distribution level, we don't necessarily need a GUI for switching it, do we? We could also just have it as an unexposed parameter in the config file.
Apr 9 2017
2.1 MB, much better! :)
The cover page looks like has some compression artifacts in the text. Is it a bitmap which has been compressed?
If so: Would it perhaps be possible to use a different format for it which can be shrunk to a usable size without any loss?
Looks good, but why is the PDF 55MB big? There must be some gigantic images in there...
That would make it quite heavy to send via email or for people to download...
Apr 8 2017
Version 2 (top toolbar, no colors) looks the best to me, with the downside that the install button does not stick out. If we go without colors, we'd probably at least need an icon for the install button to not make it totally blend with the rest.
Apr 4 2017
@paulb @skadinna To avoid such editing conflicts, I'd recommend either using notes.kde.org, the Collabora Online on share.kde.org or if it's a more complex plain-text document even creating a Git repository (there might even already be one for promo, I'm not sure).
Mar 29 2017
Mar 1 2017
Final comment: Do whatever makes sense, keep only the context menu if you like. I'm out.
Okay, personal opinion on why split buttons are among the most horrible things related to UX:
(And whilst some of these points might not apply to this very specific use case here: they will elsewhere, and once one component users this button, others will too, see e.g. spectacle)
- They are very prone to accidental clicks. If you want to click the (little) arrow but hit the button instead, worst case you get an undoable, destructive action. This gets a lot worse with touch.
Feb 28 2017
You don't have that in a file manager, either, and this thing represents a file.