VDG does not exist

tl; dr: VDG is not a single entity with “official” decisions or something different from what KDE is: everyone is responsible for his/her actions and words. Recent Martin Flöser criticism about small changes with less global vision is true.

VDG (originally Visual Design Group, now just V Design Group) was created by Jens Reuterberg during the KDE4-Plasma5 transition, it included experts from different areas and they did a great work, with a solid and coherent vision about UI/UX. Since KDE4 times, developers did an awesome work both implementing visual and usability changes and improving Plasma’s performance and stability.

Since then VDG changed a lot, losing contributors and acquiring others and because of the great work done with Plasma, developers of other KDE software started to ask for VDG’s input. We didn’t have good organizational skills, and I know we lost a great contributor just because following VDG’s discussions became impossible. More people joined discussions on Telegram groups and the small-fixes phase began.

Since the beginning sentences like “VDG said…” made little sense, but considering what VDG is now, they are totally nonsense. At the moment there isn’t a list of “VDG members”, VDG happens to be just a set of groups where people mostly discuss visual and usability issues. It’s OK, KDE definitely needs it, but sometimes developers forget it (or just try to get an “official” response to pass responsibility to an entity that does not exist) and we still get replies like “but months ago VDG said…”. VDG did not say anything, it just happened that someone helped developers on one issue, now that person is not around and somebody replied something different on the same topic.

What can we do to improve this? Following discussions I found some patterns that should be avoided by both developers and other contributors:

  • a developer asks for VDG input in VDG group, someone with no knowledge about the matter (most of the time the needed knowledge is: HIG, previous discussions about the issue, solutions provided for similar issues) shares his/her opinion and in the worst case it’s taken as an “official” reply. We have (had?) project maintainers for different areas, those should be pinged, but sadly some of them are not around anymore. While new enthusiasts’ opinion is welcome, they should be better introduced to KDE’s recent history and decisions.
  • about reverting changes, here there is a patter that often happens to me: I propose X, someone else proposes Y, then developers implement an “Y-ish X” and I agree appreciating that my opinion matters, but after a while the “Y-ish X” doesn’t work and I suggest that Y would be better. It seems I changed my idea but I didn’t: I still think that X is better than Y but Y is better than the Y-ish X.
  • on small changes against big picture: here Martin Flöser is really right, while I don’t know the topics he’s referring to because the areas I care about and the ones he’s responsible for do not intersect, some changes have been made without I was able to notice (and I think it happens to most of us, since we are hobbyists) and without caring of the effects on the big picture. This is true for Kirigami, where adapting things incrementally overshadowed Kirigami’s principles, which were layout responsiveness, UI morphing between form factors and input types, controls at the bottom on phones for reachability, space for content and less use of chrome. Revisiting these with statements like “if you want an ergonomic phone buy one with smaller screen” is not acceptable at this point. New contributors must know the principles we agreed on.
  • fragmented discussions and no traceability of decisions: here the solution is simple, let’s use Telegram groups or other channels for quickly discussions with people around and be sure that every important thought is on Phabricator, discussions organized on tasks or reviews. Be sure to follow/use VDG tag on Phabricator to get updates/ask for feedback and share the link in the right group/channel if needed.
  • about involving developers into VDG discussions: many of them joined Telegram but most don’t because of obvious reasons. I must say that I suggested to VDG to switch to Telegram from Google Hangouts when Telegram just released its shiny desktop client and the experience was really better compared to Hangouts. Most of our Telegram groups are bridged to IRC but with a poor experience. There was a big discussion in KDE about switching away from IRC for something else and since the best alternative, Matrix, is already bridged to Freenode with zero maintainance needed we basically agreed on using both IRC and Matrix: everyone uses what he/she prefers. What to do with Telegram groups? My suggestion is keeping just the groups intended for users and make contributors switch to Matrix/IRC, with most of the important discussions happening on our infrastructure, Phabricator, organized in tasks (Maniphest), reviews (Differentials), and mockups (Pholio, yeah Phabricator’s app names are terrible but hey, still better than use Microsoft GitHub).

Thanks for reading.

Comments (Markdown supported):

  1. Pingback: #VDG does not exist http://www.alexl.netsons.org/713/ “VDG (origina… | Dr. Roy Schestowitz (罗伊)

  2. Pingback: Destination Linux

  3. Pingback: Destination Linux

  4. Thomas

    Thanks for clarifying the VDG.

    “Recent Martin Flöser criticism about small changes with less global vision is true.”

    Do you mean this is true in KWin only or in all KDE projects? If not all which ones? On phabricator I read that one goal of KDE’s global vision is to increase usability and this is often achieved with a lot of small changes. I think it is important to make it perfectly clear which changes are considered “good” and “bad” so that everyone can learn. Otherwise, this statement creates an atmosphere of doubt.

    1. “Increase usability” is not a vision, every project wants to increase usability. “Don’t put controls at top in mobile UI” is a piece of vision.

  5. Tuukka

    Do you think it would be good if VDG did exist? I mean a group that’d formulate coherent ideas and opinions based on consensus? Obviously that would be less democratic as the group should be able to pick its members, but there would obviously also be some benefits.

    Is that something that might sound good in theory but wouldn’t work in practice? Or is it just that nobody has time to organize it?

    1. In KDE there isn’t a democracy but a meritocracy: who does the work decides. The way it is now it’s OK because KDE needs a place to discuss visual and usability issues, but the problems I described must be solved.

      1. Vincenzo


        I think that attitude is partly wrong since it might miss the end user’s perspective. Let’s admit it: many developers “don’t live in the same planet” than your father, my aunt our neighbors or even me, one of those “power users” with some system administration skills but no developer at all.
        There should be a sort of “chair” representing “we, the people”.

        Let me illustrate with a few real ang verifiable examples:

        There was a discussion in bugs.kde.org few years ago about adding a user configurable delay for Plasma panel when set to hide and show automatically (very useful to gain some screen real estate on small screens, like those in laptops) because some user thought it was too “sensitive” and any slight approximation of the cursor to the lower border of the screen would make the panel emerge immediately, interrupting his/her workflow. I didn’t say anything because I have used panel auto hide just very seldomly, but it’s true that it was thrown to your face unexpectedly evey now and then, forcing you to stop what you were doing (using the search/replace box in a maximized Kate, for instance, since panel would cover the lower part of Kate’s interface), moving your cursor away, wait for the panel to hide again, and then go back to what you really wanted to do, but with much care to not triggering again the hypersensitive mechanism of the panel’s showup. It was a real usability nightmare if you tried to work for a couple of days with that auto hide function on.
        Well, thanks to that “meritocracy”, Martin Flöser just said “wontfix because I don’t think that’s a real problem nor the effort is worth it”, and no power on Earth could change that decission.
        Now, most people I know who are heavy auto hide panels users have switched to Latte dock, which allows configuring delays for both hiding and showing the dock. But for years there wasn’t any real, comparable, alternative to Plasma’s panel.
        HTML email. Do I need to say anything about how stubborn have been KDE developers during more than a decade trying to convince users that the world was wrong about HTML in emails, and since them, the Kmail developers, were the smartest guys on Earth and were sticking to tradicional plain text mails, every living being should do the same? It took , no exaggeration, more than a decade that finally new and more reasonable developers decided to take the rendering and composing of HTML mails seriously.
        Dolphin still hasn’t a history, like every file manager has since Windows 95 times, and of course Konqueror had too. There was even a proposal submitted to that nice section called “Brainstorm”, that was rather active many years ago in the KDE forums. Well, again that saint meritocracy made a sane proposal like that vanish on thin air because developers thought “If I don’t need it nobody else will do”.
        Kjots still doesn’t support image embedding. Again, I’ve read more than half a dozen of proposals in forums, comments to blogs, requests in BKO… Nothing. People is switching to Markdown editors even if many of them lack a real user friendly (WYSIWYG) interface, but at least attaching media just works.
        Last but not least: Please, stop adding secondary features or “obscure” bug fixes that only affect developers before small everyday bugs that make Plasma unrecommendable for non computer enthusiasts are fixed.
        I’d love to make my realatives and friends come to the “free world” and increase the “mass” of Linux users who might force hardware makers to take our OS more seriously, but I honestly can’t install a Linux distro with my favorite desktop, Plasma, when I know that in few months my mother will call me to tell me that something has been broken after some update or my dentist brother lamenting because some file has been corrupted gods know how, and his desktop just shows a black screen and a mouse cursor; small issues that all of us have suffered along our “KDE life” and solved in 10 minutes after searching on the Internet or asking in some Telegram group; but common computer users who, as I said before, use their computers to work, study, entertain, etc, would feel like if you had to repair your car by yourself. Of course let’s not even think about asking those unsatisfied users to donate for the project… xDD
        Some influence from a “people’s chairman” could be productive at this respect and perhaps restrain some of that “developers’ onanism”, IMHO.

        And I could go on with similar examples. So, I think that a “chair” for those requests and suggestions made by end users, by people who use KDE/Plasma for real work/computer usage, not just for hacking, would be very beneficial. Keep on with that meritocracy, ok, but don’t let it become a “fascist regime”.
        Of course I’m not talking about making every average Joe as “powerful” in decision taking as an experienced developer, I talk about power users and consensuated ideas and requests. Not real “democracy”, but a sort of “aristocracy”, the “government of the best ones”, according to the ethymology, both from the developers’ and the users’ worlds. Because if you keep the KDE echosystem just following personal desires and egos (let’s not forget about that; we all know the entire community has suffered many consequencies due to some devs’ egos) not letting the “qualified users” do some “corrections” in the directions the projects follow, you won’t be doing things as well as they could be (again, does anyone really think that you need to click the back arrow in Dolphin 11 and check if any of those is really te directory you want to go back times instead spreading a popup with the visited directories? Imagine you had to do the same in your web browser…). And let’s not talk about financing. I think I’m not the only one that has heard some users say that they have stop donating because after years reporting an annoying bug or a common feature that’s available in other desktops and OSes, the developers keep thinking that it’s more important to have pretty icons or graphical effects.

        I hope you and any developer that might read this will take it as a constructive criticism. There’s no other intention in this comment (too ling, BTW, excuse my verbosity) than make KDE/Plasma better and more close to real computer usage.

        Thanks for reading, many, many thanks for the, despite the mentioned deffects, fantastic KDE/Plasma echosystem, and let’s hope that said meritocracy could become a bit less authoritarian and a bit more open to dialoge with the majority of final users.

  6. Anton Latukha

    To make a real UI you need to gather activity information from volunteers.
    How people use UI, what applications launched, buttons clicked, hotkeys used.

    And then watch tracks of actions.

    Split user stories by category: developer, system administrator, art person, power user, normal user, newcomer.

    And decide what role applications should have. Like Krita needs to keep a laser focus on painters, Inkscape on designers, digiKam on professional photographers.

    From my view, without tool that allows volunteers to provide KDE needed information, – KDE interface can only go so far in understanding what to do in UI perspective. Since KDE has many features, buttons etc. it is very needed.

    1. Are “volunteers” (who join discussions and report bugs) representative of user base? I don’t think so. Should we gather data from users’ PCs? We shouldn’t, we should just continue as we did and improve organizational and communication skills.

      1. Beluga

        So you are against this thing that is actively being worked on: https://community.kde.org/Policies/Telemetry_Policy ?

        1. I’m not against it because those are not the data I was referring to

      2. This is also a way.

        But I wouldn’t mind free software projects gather my data, and always was interested to be able to send usage statistics to KDE.

        Gathering some level if totally OK for me.
        Ubuntu gathering numbers of installs, CPU architecture, size of a display and resolution is totally OK. Otherwise, they don’t know who are the people that use their project.

        Right now as I browse, ad companies without my concern gather data about my laptop, browser, resolution and they detect me fingerprint, and slap that data to the information folder they have on me , whenever I go with this laptop.

        NSA gathering all the information.

        And we flip-out that Ubuntu wants to know their market share and direction how to develop the distribution.

        Ubuntu feeds user data to Amazon spyware lence in 2015 – bad.
        Ubuntu gathering basic statistic from volunteers in 2018 – good.

        As long as project is free software, and I know, can see, and have control over what data they receive about me – I am totally OK about it, and try to encourage it. On my view free software projects can ask me and even sell that data on the side, if info is not storing my secrets.

        Because some harm companies steal my data and sell it.
        I use free software, and if I help and can give out my data to pay back something – it is an honest relationship.

      3. I am also both hends for better bug reporting in KDE.
        I love KDE, but I got into maintaining atk-spi2 packages, and drive-by bug reported several bugs already, because workflow is unified and it is easy to do drive-by report.

        While I love KDE, I reported several bugs, but I don’t eager to go to bugzilla. And I deliberately look for duplicated reports, and didn’t find any, then I file a report and after – find a duplicate, or being merged by developer. Because UI is confusing.

        You know it’s better than me.

      4. Vincenzo

        I think Anton Latukha is right. Even if I understand your skepticism (how to be sure, right?), I also believe that most bug reporters for, say, Krita, really are people who use Krita in some deep degree, not just for playing, especially those who report detailed and well explained bugs. As I said in my long post before, I think that you should respect power users a bit more. They probably don’t know how to write software but many might know how the software you write works in diverse scenarios in real use cases; maybe they know it even better than you, seriously. It’s not the engineer who really knows if his machine works right but the people who use it every day.

        About gathering data… Why not making an optional “collaborating program” for users who want to support KDE’s development providing those data? GBD and other debugging tools aren’t installed by default but collaborative users voluntarily use to help developers solve bugs. This could be something similar.
        The problem with data gathering would be if other info besides strictly technical and anonymous data were gathered, and/or without the knowledge and consent of the user. But if no private data is gathered, only the minimal possible data necessary, and only upon user’s explicit agreement, what’s the problem?
        If you really aren’t very convinced about this, why not making a poll or something like that in KDE related websites (The dot, KDE Planet, etc)?

  7. Andreus

    If I am not mistaken the problem with KDE Plasma was reliability, as to not call it “stability”, not usability.

    The way to get there is known: excessive testing, attention to detail.

    We know from past experience how to enthusiastically destroy a project. Amarok is a good example. No coherent vision. Youcandoeverythingwiththenewarchitecture nonsense. And the ported version does not provide the user experience of the successful model. Result: project dead.

    What do people want? A fast and responsive desktop with a low memory footprint, dark and light theme, that never crashes and gets never even noticed by the user. Thus provide the basis and test it paranoid to never crash. No useless popups. No confusing messages. No annoyance.

Leave a Reply