User Details
- User Since
- Apr 8 2016, 6:32 AM (415 w, 6 d)
- Availability
- Available
May 5 2020
May 4 2020
Apr 14 2020
Seems to be because I still had the "Differential Revision" field in the commit message:
Apr 13 2020
Apr 12 2020
Created the merge request at https://invent.kde.org/websites/hig-kde-org/-/merge_requests/73
Sorry for responding so late as well. I'll re-submit according to the instructions you provided.
Apr 4 2020
As a side-note, I just wanted to mention that the Contribute section in the HIG doesn't actually explain how to submit the changes you make locally. I followed the instructions from this Community page. I'm not sure if this is correct and it actually took a bit of searching to find. So it might be useful to include up-to-date instructions on the Contribute page in the HIG, even if it's just a link to that same page (assuming that's the correct workflow to use).
Oct 13 2018
So if it's okay with you, I'll accept the patch now, and after it's landed, I'll put on my liberal arts degree hat and submit another patch with proposed changes.
Sounds fair. I look forward to see what you make of it.
Oct 8 2018
- Some more fixes based on feedback
I removed the glossary now and changed the reference link to point to the new one. Can someone verify that it's correct? I'm not too familiar with Sphinx.
Oct 7 2018
- More changes based on feedback
I fixed most of what's mentioned in the feedback. I didn't quite agree that the user stories weren't relevant for Susan which I explained in the reply to those in-line comments.
Based on the feedback about the pointing device, I decided to also explain the benefit of having a keyboard. This could then replace the part about "traditional-style input" which was too vague anyway.
Oct 6 2018
I fixed most of what's mentioned in the feedback.
- I removed the netbook, smartwatch and tv device types.
- I tried to rephrase everything to be more succinct. Let me know if this is sufficient.
- I put manual line breaks at 80 characters
- I created a separate Glossary page (which was still left from feedback by @fabianr)
- I updated the screenshot with the new component names
- Modified again according to further feedback
Sep 23 2018
Thanks for reviewing. I've replied to some of the comments, and fixed the other ones.
- Modified according to review feedback
Sep 11 2018
Even with "Solid" as design principle, I wouldn't say that this translates to translucency being off by default. Moving a window is inherently a transient state, so it might feel strange if we try to make this stable or rigid (in UI/UX terms).
Sep 9 2018
I agree that we shouldn't focus too much on specific guidelines (the micro direction) but I do think it helps us understand how these principles could be applied to such guidelines. That in turn should help define the principles in a way that they can correctly be applied to new guidelines later on. Especially since we're essentially working with a bottom-up approach, trying to extract the principles from the currently applied style, I do think a bit of micro discussion is unavoidable. But it's definitely good to keep the conversation on track.
Sep 8 2018
I would not consider the Breeze color palette https://hig.kde.org/style/color/default.html very subtle, but rather strong and vibrant.
Looking at the Breeze color palette, I think most of the colors are matte (which I think is a good thing). They aren't highly saturated colors, if that's the right term for it. But my reason for choosing "Subtle" as a design principle isn't just because the colors are somewhat matte. If you look at how they are applied, you usually see a single color (or very few main colors) which are decorated/highlighted with a few other colors. To me, this comes over as a very subtle use of color.
Sep 7 2018
However, that motto feels a lot like an operational motto. It is the way we "do" things rather than the way things "are", a more "procedural" approach rather than a visual one.
This was exactly why I didn't think this motto worked as design principle. Thanks for explaining it so clearly.
Aug 29 2018
I created a list of common (visual) components a while ago that may help with this. I tried to define what visual elements are usually available on any device, with a description of its intended functionality. This description is a bit abstract but I also provide more concrete descriptions of what exactly is used for each component on a specific device type.
TL;DR I think the KDE HIG needs to use a unifying concept as its main principle. This is likely to be vague but you can explain how it relates to the HIG. An example of such a unifying concept is kirigami (the art of folding and cutting).
Jun 1 2018
A while ago, I did some research on how convergence might work. I ended up with an overview of possible device types and a description of the corresponding user experience. I also tried to identify common elements in the UI that would need to be converted in order to move from one device's UX to another. I've documented this on the community wiki:
https://community.kde.org/Plasma/Convergence_Overview
I also created a forum topic for feedback, which you can find here:
https://forum.kde.org/viewtopic.php?f=285&t=131170