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

n7ipb's picture

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

Take Our Poll
Filed under: KDE

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