This week in Discover (and Kirigami!), part 6

This is going to be a double-header: today we’re discussing Discover as well as Kirigami–KDE’s UI framework that facilitates writing convergent apps that look and feel good on both the desktop and a mobile device.

…At least that’s the idea. The truth is, KDE users have voiced a lot of criticism for how well this works out in practice. An especially common complaint is that the desktop user experience gets short shrift, and Kirigami apps feel like big phone apps.

We’ve heard this feedback, and we’re acting on it. Over the past week, we’ve been hard at work to make Kirigami UI components behave more appropriately on the desktop, and have Discover make use of them instead of its custom components.

So I have exciting news for everyone who has complained about Discover’s design being too mobile-ey and wasting too much space: that’s going to be a thing of the past. Here’s how the Featured page now looks in git master:

No more huge header with the picture of the coffee cup that nobody liked! This is not the final appearance; there’s still polish work to be done, and we are heavily iterating over Kirigami to improve it to make the Desktop UI a first-class citizen. But it’s a model for what we’re going for.

We also added some other much-requested user-centric features to Discover, such as making reviews more prominent. Have a look!

  • Discover now shows the top three reviews right on the app page (KDE bug 380514, implemented in KDE Plasma 5.13):
  • Discover’s review submission pop-up is now more user-friendly and makes it impossible to accidentally submit a one-star review (KDE bug 390426 and Phabricator revision D10500, improved in Plasma 5.13):
    Note the presence of a close button! Another much-requested feature for Kirigami pop-ups.
  • You can now use Discover to write an app’s first review (KDE bug 390339 and KDE Phabricator revision D10476, fixed in KDE Plasma 5.12.1):
  • Kirigami scrollable pop-ups (used for Discover’s review page) no longer let you scroll beyond the content in desktop mode (KDE bug 388942, fixed in KDE Frameworks 5.44)
  • Kirigami non-scrolling pop-ups (used for Discover’s review input pop-up) now have correct bottom padding (KDE bug 390032, fixed in KDE Frameworks 5.44)
  • Kirigami toolbar headers are bit taller their titles and navigation buttons have appropriate padding (KDE Phabricator revisions D10483 and D10524, fixed in KDE Frameworks 5.44)
  • Kirigami pop-ups (used for Discover’s screenshots and reviews pop-ups) now have close buttons (KDE bug 387815, Fixed in KDE Frameworks 5.44)
  • Discover’s “show more reviews” button now always shows the correct number of reviews, has slightly better text, and no longer lets you write the first review for apps that you haven’t installed yet (KDE Phabricator revisions D10527 and D10525, Fixed in KDE Plasma 5.13)
  • Items in app lists now have better top padding, so they don’t touch the header (KDE Phabricator revision D10548)
  • Improved the metadata for the KDE Nightly Builds Flatpak repo so it has a more appropriate name, in preparation for encouraging our users to try it out (more on that soon…):

Well there you have it. We never stop working on improving Discover, and we really do listen to user feedback. Mark my words, Discover is going to become one of the most-loved Linux software centers, you heard it here first! Help is always appreciated, so feel free to start contributing and making a difference to a project that truly matters. You don’t have to be a programmer to have an impact!

And if you look at my efforts and like what you see, consider donating on Patreon to help me do it full-time, rather than squeezing it in before and after my regular job. With your support, I could bring forth even more for KDE!


This week in Discover, part 5

This week Discover gained a lot of little UI polish improvements, and Discover developers also fixed a major crash present in 5.12.

  • The main Featured page now shows more apps on distros like Ubuntu and KDE Neon that have lousy AppStream data (KDE bug 390016, fixed in KDE Plasma 5.12.1):
  • Notifications now stick around for longer, so they’re easier to read (KDE bug 388087, fixed in KDE Plasma 5.12.1)
  • Discover’s button that takes you to the page where you can write a review now has correct padding within its overlay (KDE bug 390030, fixed in Plasma 5.12.1)
  • Fixed a prominent crash in 5.12 when searching from the app page, deleting the search term, and searching again (KDE bug 390114, fixed in Plasma 5.12.1)
  • Discover’s review submission button is now labeled “Submit” (KDE bug 390031, fixed in Plasma 5.13)
  • Discover’s review submission button is now visible but disabled for apps that aren’t installed yet, not gone entirely (KDE bug 390053, fixed in Plasma 5.13)
  • Discover (and all other Kirigami apps that have High-DPI and vector imagery) now look crisp and sharp when run in HiDPI mode (KDE bug 390076, fixed in KDE Frameworks 5.44)

If you like what you see, consider becoming a KDE contributor and join the team! The speed of improvements is pretty directly proportional to the amount of help we have, so the more hands on deck, the better KDE software becomes!

App popularity in Discover

Currently, Discover sorts apps by popularity. In this case, popularity means “number of ratings”, and ratings come from user reviews. This is why GNOME Tweak Tool shows up first in Discover’s browse list: apparently it’s very popular among GNOME users, and they’ve written lots of reviews about it. We should all follow their lead and write some quality reviews about our favorite software; this helps the best apps bubble up to the top, and users love reading reviews from other users when determining whether or not to install an app.

Here’s how to write a review in Discover:

First, browse to an app page, and click on the “Show Reviews” text to open the Reviews pop-up:

Now Click on the “Review” button to write a review:

Now write your review, then click Accept:

Worth mentioning: the visual imperfections you might have noticed in the above screenshots are tracked by KDE bugs 390030, 390031, 390032, and 390035. We also have plans to make reviews more prominent (KDE Phabricator revision D10237) and allow sorting by criteria other than popularity (KDE bug 383518).

What to write in a review

Here are some examples of unhelpful reviews:

  • “1 star, it crashes on launch on Debian 3”
  • “1 star, doesn’t have this one specific feature I want”
  • “1 star, Electron apps are the worst! Rewrite it in Qt/GTK/Wx/ncurses you n00bs!”

These reviews don’t communicate much useful information, or will quickly become inapplicable. Useful reviews are about the app itself, not the conditions in which it’s run, or the toolkit of programming language it’s been created with, or any one particular annoying bug. They honestly describe the app and its features, usefulness, and impact in a way that will be relevant to uses in a month, a year or even later. Reviews like this are a blessing to users everywhere, and make it easier to find new apps.

So go out there and review your favorite apps!

This week in Discover, part 4

In preparation for the impending release of Plasma 5.12, this was a big bug-squashing week in Discover thanks to lead Developer Aleix Pol, who knocked out a huge number of reliability and stability issues in Discover! We also got in a few UI polish and usability improvements, too.

  • The number of available updates is now always consistent (KDE bug 389108)
  • Update notifications are no longer shown twice in certain circumstances (KDE bug 389429)
  • Fixed a crash when opening Discover with the Flatpak backend installed, but without the system Flatpak libraries (KDE bug 380496)
  • Fixed a crash while searching (KDE bug 385679)
  • Fixed a regression where the screenshot overlay would lose keyboard focus (KDE bug 389510)
  • Fixed a memory leak when browsing the Plasma Addons category (KDE bug 387630)
  • Made the Reviews pop-up have less side padding for better readability and usability (KDE bug 389536)
  • The scrollbar on the settings page no longer overlaps interactive UI elements (KDE bug 389602)
  • Repo list items no longer expose redundant Filter buttons (KDE bug 389767)
  • Discover’s settings page displays repos in a much more usable and readable manner (KDE bugs 389714 and 389715):

“Xenial (Main)” being listed twice is a bug we’re working on; the second one is the source repository, but it doesn’t communicate that. Little by little!

It’s constant improvement like this that adds up over time to produce great software. We think you’re going to love Discover in Plasma 5.12, and we’re continuing to work on making it even better!

If you like what you see, please consider helping out! If we were pirates, we’d say, “yer money or yer time, yarr!”

This week in Discover, part 3

This was a design-heavy week in discover, and we landed some bold design improvements to the Application page:

In addition, we fixed bugs, including a few corner-case issues for workflows where Flatpak apps are available alongside apps from your distro. Flatpak support is constantly improving! There are always lots of backend improvements, but here’s the full list of this week’s user-facing improvements:

  • The search field now works again after you go back from an App page, and other focus-related improvements (KDE bug 388835)
  • Long app titles in titlebar are now displayed without eliding, if possible (KDE Phabricator revision D9995)
  • After installing a Flatpak version of an app, trying to launch the PackageKit version from Discover correctly opens the Flatpak version (KDE bug 389036)
  • When an app is available from two Flatpak repos and a PackageKit repo, switching its source to a Flatpak repo no longer makes the PackageKit version temporarily disappear (KDE bug 389186)
  • When the app defines them, show URLs for the user guide, donation page, and bug tracker (KDE Phabricator revision D10131):
    Good Inkscape.png

How to make an app look good in Discover

Why do some app pages in Discover look good, while others look half-finished at best? Why is it that sometimes in some distros (Like Ubuntu 16.04 and KDE Neon) almost all of the app listings are bad? We’ll dive into that today, and see what the plan is for fixing it.

First thing’s first: Discover does not control an app’s presentation. Instead, we display app metadata (such as screenshots, the description, and links to the app’s website) made available to us by the software’s packagers. It’s all up to them to pass on the metadata. If they don’t give it to us, we can’t display it to you!

Where does this app metadata come from? The app developers themselves, from their AppStream file. If an app doesn’t provide an AppStream file, or its file is very minimal and doesn’t provide much content, then the packagers have to create this information themselves. Some packagers do a better job of this than others, as we’ll see. Ubuntu 16.04 is a particular offender, and while it’s gotten better in later releases, every distro based on Ubuntu 16.04 (like KDE Neon) will unfortunately inherit its deficiencies of metadata-poor packaging. This causes app listings to look bad, and frustrated users blame us or the software developers–almost never the distro, even though they make this their job!

Here’s an example of what good AppStream metadata can do for an app:

Perfect Hexchat.png

It’s got:

  • An attractive, high-resolution icon
  • A screenshot
  • A short and useful description
  • A human-readable version number
  • A license
  • URLs for the homepage and user guide, plus links to pages where you can donate or report a bug.

All apps should look this good! It’s pretty easy to get there if developers put lots of information in their AppStream metadata files, and if distros and other software sources make it available to us. Here’s Hexchat’s AppStream file. This is what a good AppStream file should look like! (there’s only a single problem: the ID is set using a non-recommended form: io.github.Hexchat.desktop. This string shouldn’t have “.desktop” on the end of it).

So what’s the plan? We need to get app developers to improve their AppStream metadata. This is an ongoing effort that I’m heavily involved in, but like everything in the FOSS world, it will go much faster if you help!

How users can help

Let’s say you stumble across an app listing that looks like this:

Bad Filezilla.png

There’s no screenshot, and the text looks like it was formatted using Markdown, which isn’t formally supported in most software center programs like Discover, so it shows up as an ugly wall of text. The license is “unknown”, and there’s not even a URL for the app’s website! What a mess.

Here’s another:

Bad HoDict.png

This app provides a low-resolution icon that isn’t very attractive. Its caption (“Ho22bus’s Dict”) gives no indication what the app is or does. As before, the description appears to use markdown rather than HTML, and provides no license or relevant URLs. The app is a mystifying black box.

Here’s how you can help software developers!

First, find the app’s source code repository. Then, within that, locate the AppStream file. It’ll be named something like[appname].appdata.xml. If it looks fine in the developer’s source repo, and you’re using a distro that ships old software like Ubuntu or Debian, it’s likely that the distro packagers simply haven’t included an up-to-date version of the AppStream file, so file bug on the distro’s packaging itself asking them to.

If the file is subpar… then fix it! On the technical side, check out Hexchat’s AppStream file for a great example of how it should look. Design-wise, here’s a great guide from the ElementaryOS people on how to write a compelling app listing that’s largely applicable to Discover as well.

In some unfortunate cases (e..g. Blender), there may not even be an AppStream file. Well, submit one for them! This stuff is really important!

Make sure to validate the file using an XML Validator, and then once it checks out as being valid XML, run appstreamcli validate on it (you may have to use your distro’s command-line package manager to get appstreamcli). Once it passes both checks, submit it back to the developers, either in a bug report, or even a patch or pull request if you know how to do those things.

How developers can help

Please: provide downstream packagers with AppStream files that you’ve taken the time to craft with love and attention to detail. Distros may do your packaging for you, but they’ll never care about presenting your app nicely as much as you will!

If you don’t supply packagers with high-quality AppStream metadata, you’re making life harder for packagers, and your potential users may well be presented with an ugly, even repellant app listing in software center apps like GNOME Software and KDE Discover. Users may blame you, or they may blame us, but either way, they’ll be looking for someone to blame, because bad or nonexistent AppStream metadata will make your app look bad, guaranteed. Here’s the spec. Follow it, and make your app look beautiful, and users will trip over themselves to install and use your software.

Also, submit your app to Flathub! The Flathub people are easy to work with and are delighted when you include high-quality AppStream metadata. Which leads me to…

Flathub rocks

I want to give a shout-out to the people who run Flathub, the de facto central repository of Flatpaked software. They take their role as packagers seriously, even going so far as to create high-quality metadata for apps that lack it. For example, here’s the version of Blender packaged in KDE Neon, which comes from Ubuntu 16.04:

Blender bad.png

Doesn’t look too great, right? Blender is amazing, but you wouldn’t know it by looking at this. Sadly, the Blender developers don’t provide an AppStream file, and the Ubuntu packagers didn’t do anything about it. So Blender’s app page looks lousy.

But here’s the Flathub version:

Blender good.png

Isn’t that way better!? Lots of screenshots, paragraph breaks, a license and website URL… all that information was added by the Flathub packagers. Now that’s dedication.

Want to help out? Be like the Flathub people and improve the metadata for your favorite apps, but then go even farther: submit your changes back to the developers! Here are some examples of minimal patches I or others have submitted to give you a sense of how easy this can be:

Get out there and make some apps look good!

Discover makes your app look gooooood

A common user complaint about Discover has been that the design could use some improvement. We set out to remedy this in the soon-approaching release of Plasma 5.12, with the aid of KDE’s Visual Design Group. VDG members came up with endless ideas and mockups, and we spent weeks discussing things and iterating on the design. I wanted to share the evolution of a single view in Discover: the application page.

In Plasma 5.11, here’s what we started with:

Not bad! But there were some rough edges we wanted to address. The header was full of technical information that wasn’t always what you wanted to see first. The screenshots needed polishing. And that toolbar on the bottom used a nonstandard UI convention.

First, we turned the bottom bar into a real toolbar like the kind that appears on the top of a window:

That fixed that problem, but it made the app display on top a bit disjointed, and exacerbated the problem with having the app metadata on top. And having the app name and icon only in the toolbar made it easy to mistake the caption for the name!

We resolved that by moving the entire metadata section below the description to reduce its prominence, and returning the app name and icon to the page itself in a simplified form:

This revision got high marks internally, but we wanted to go further and ensure that users of Discover in 5.12 received a really polished experience. So we further tweaked the header, increasing the size of each element to increase its visual prominence, and adding a bit more padding. Then we made the screenshot thumbnails reflect the aspect ratio of their full-sized images and gave them a drop shadow to make them pop:

Next, we decided to improve the whitespace and padding even more. We moved over the app name and caption a bit, increased the margins on the sides of the page, and made the description text left-justified:

That screen looks really good because Krita provides an even number of screenshots that all have the same aspect ratio, and they fit perfectly in the window size that I’ve chosen here. But for apps and window sizes that deviated from this, it didn’t look as good. We also felt that the shadows provided a bit too much depth, and competed with their content. Finally with more than four screenshots, the text was pushed down so far you needed to scroll just to see it. So we decided to reduce the shadow strength and put the screenshots in a horizontal scrollview:

This helped! We decided to implement a fade effect when a thumbnail is cut off, and we made the them bigger and taller because with the design, there will only ever be one row:

Whaddaya think? I’ll tell you what I think: it’s fantastic, and you guys are going to really love this app view. I’d like to thank KDE contributors Andres Betts, Andreas Kainz, and Thomas Pfeiffer for their help with the design work, and Aleix Pol for technical work–and for letting me work on his baby Discover in the first place!

Here are some more screenshots showing how it looks with other apps, and in the smaller Plasma Mobile view:

There’s always room for incremental improvement, and there are a few more tweaks we’ll probably make before Plasma 5.12 is released. But we don’t currently have plans to make any radical changes here. We think you’re all going to love this design in Plasma 5.12!

If you like this kind of work, consider jumping on board and helping to push KDE software to even higher heights! Donating helps, too, and allows KDE to sponsor more work and help students travel to KDE events.

Another important task is to get your favorite software to improve its AppStream metadata! Version numbers, screenshots, better text… the better the data we get from apps, the better we can make the app look in Discover.