A Usability Guy’s Journey to Creating his First KDE Tool – Part 2: A Vision

Advice

As already suggested in the first article of this series, fixing a bug was just the start of my journey. What I now want to do is help KDE improve our AppStream metadata. Why is this so important to me?

I first got in contact with AppStream as part of my interaction design work on Discover. The fact that all I had for linking the word Discover to was a not very informative quickgit project page perfectly exemplifies one of two big problems that I want to help solve: That only a minority of KDE projects have a proper representation on the web. The other issue is that the default software centers for Plasma (Discover) as well as GNOME and Unity (both use GNOME Software) both draw the information they present on applications from AppStream data, but far from all of KDE’s applications provide these data.

The nice thing is that we can reuse the information for AppStream to automatically create a website for each application which is at least a lot more informative for end users than what quickgit provides. Of course, those projects who have the manpower and motivation to create gorgeous websites like that for Minuet or Krita should still do that, but the others would still get at least something useful.

Of course I am aware that AppStream metadata do not grow on trees. Someone has to write them. AppStream database builders read metadata about an application from an appdata.xml file provided with the application’s source code. Now I know that just seeing the extension “.xml” is enough to raise many developers’ neck hair. The fact that developers have to write an xml file by hand may be one of the reasons why not everyone does it.

It may not be the only reason, though. Maybe people need to be reminded that they should check before release whether their AppStream data is up-to-date? Maybe they need AppData generation and maintenance to be better integrated into their workflow?

I want to help developers to create and update their applications’ AppData more easily, and I want to create a tool for that. For now I’ll call that tool AppData Helper.

This is its product vision:

AppData Helper is a tool that makes it easy for application maintainers and developers to create and maintain an AppData file for their application. It takes as much of the “bureaucracy” out of the process as possible, allowing them to focus solely on the actual information they have to provide.

Now I have two questions for you, dear potential users. First of all: Do you think such a tool may make it more likely that you provide AppData for your application? Please answer that question in the poll below. The second question is: What specifically would such a tool need to do in order to be of help to you? Would it have to be a GUI application, a command-line tool/script, a KDevelop plugin, or something else? Please provide input for that in the comments!

Thank you,

Thomas

Researcher on usability / usable security / user experience Volunteer KDE usability consultant Open Access / Open Science supporter

Tagged with: ,
Posted in KDE
18 comments on “A Usability Guy’s Journey to Creating his First KDE Tool – Part 2: A Vision
  1. Elvis says:

    Yes, XML is bad, but I don’t think that this is the reason why some devs are not writing appdata. If a project is not maintained there is very little we can do. I think the main reason is that maintainers (when we have them..) are already overwhelmed by work and appdata just happens to be on the bottom of their todo list.

    Why not involving the community in this? Why not setting up a website where people (not necessarily developers) can easily add/edit/update the metadata? Let’s say this server saves the metadata in some format, e.g. JSON. Then it would be “doable” to auto-generate the XML appdata files out of those JSON files.

    And btw those JSON files could also be used in place of the JSON files defining the kde.org/applications/ pages (e.g. [1]), which are currently hosted on the SVN servers and really a pain to update😦

    [1]: https://www.kde.org/applications/graphics/digikam/

    • Thank you for the input!

      About the kde.org/applications JSON files: Actually, if I’d read this thread ( https://mail.kde.org/pipermail/kde-community/2016q1/002595.html) correctly, this seems to be the plan anyway. Or is that yet a different thing? If it is then yes, that should be done.

      • Elvis says:

        Yeah it is kind of similar. On that thread there was a proposal to centralize the metadata in a git repository. Problem is, only sysadmin would have write access to them. I like the idea to centralize the metadata, but it has to be easily writable by every kde contributor.

        • That was the initial proposal, but then people argued that it would make more sense to get the data from the AppData files because everyone with commit access can write them, and it sounded to me like that argument won in the end.

    • tosky says:

      Matthias wrote a longer answer in a blog post, but please don’t assume XML is old and bad and YAML (and JSON) is new and cool and ponies. There are different use cases and XML covers this better.

      As for the website, yes, the idea is to use the existing decentralized AppData files and use them for the website. Please note that those AppStream files are translated and covers most of the applications, so I don’t see this big issue with writing them. A really small group of people can add the missing one in a weekend.

      PS. The problem with JSON files on SVN is not SVN, but the restricted access to that specific directory tree.

      • Hmm, for that I wonder if a tool like the appstream-generator[1] can be used to automatically accumulate the AppStream files.
        Asgen is designed for distributions, but maybe writing a “KDE” backend and using the CI-built data as fake “Packages” would work… You would even get free QA by that, and one large YAML or XML file containing all metadata KDE has.

        On the other hand, just writing a custom tool which builds HTML websites out of metainfo files might be the easier approach here. The CI system could accumulate the appdata/metainfo files for the tool, and then you could transform them into arbitrary formats, for whatever usecase is needed.

        [1]: https://github.com/ximion/appstream-generator

  2. Zanny says:

    There are a lot of metadata files we would like projects to maintain. Personally I’d really like to see applications providing apparmor profiles, or at least some kind of MAC profile so we know what the default mandatory permissions should be without combing the whole source tree.

    I’m wondering why appstream doesn’t support in its standard the YAML version Debian uses. I personally love writing YAML, and would find it almost cathartic to write generic appstream data for KDE projects in YAML. Like you mention though, XML makes me want to rend flesh. It is also interesting that Debian and co are the only real distros providing comprehensive appstream data in the first place – mostly through their YAML files – whereas on distros like Arch Discover is basically a bad pacman frontend.

  3. You forgot the web. A simple webclient with columns to enter description and upload screenshots would also do. It would be much simpler. Google Play also works in similar way. No app data is stored in the app manifest and you enter info for Google Play on the developer console.

  4. maverick says:

    Hi,

    this might be off-topic and not be the right place or post to talk about this, but here it goes:

    A few time ago i’ve heard of an initiative called Bodega – it was a store but not an AppStore. It contained software but was not limited to it (i believe you’ve know what i’m talking about…).

    That idea – bodega – is apparently dead, but i believe it was not a bad idea, so here’s the 1 million dollar question: is there any plans to extend appstream beyond apps???

    It would be great to be able to enter the store (E.g.: Discover) and download a book, a picture, a widget, a music or even a movie, etc (nothing against the law, of course).

    • It is a bit off-topic here, but I have good news for you: Exactly that is planned! Discover will get support for all kinds of resources that OCS (the protocol that powers for example opendesktop.org) supports.
      So yes, Discover will become pretty much what Bodega was aiming to be.

  5. […] is a question raised quite often, the last time in a blogpost by Thomas, so I thught it is a good idea to give a slightly longer […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: