Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quality guideline improvement proposal #414

Open
xanscale opened this issue Dec 29, 2024 · 2 comments
Open

Quality guideline improvement proposal #414

xanscale opened this issue Dec 29, 2024 · 2 comments

Comments

@xanscale
Copy link

xanscale commented Dec 29, 2024

i love the idea of quality guidelines, but currently some applications have no possibility to apply them. I would like to propose some small changes that would greatly expand the possibility of joining them.

there are the actual ones and my proposal

first:

  • App Name: Shorter than 20 characters
  • App Name: Shorter than 20 characters (25 if exists multiple flavor of same app)

second:

  • Summary: Shorter than 35 characters
  • Summary: Shorter than 35 characters (45 if exists multiple flavor of same app)

third:

  • Screenshots: Reasonable window size

In order to ensure that text and interface elements are visible scaled down in the app store UI the window size should be 1000x700 pixels or smaller (2000x1400 for HiDPI).

this should just specify if the size are shadows included or not

fourth:

  • Screenshots: Just the app window

Use the "window screenshot" feature in your native system screenshot tool to get just the app window and its shadow. Do not include the wallpaper behind the app or even the entire desktop. Do not edit the screenshot, crop it, add text, or include promotional graphics.

it's not clear if we can crop the window to show some particular detail. it can be usefull for complex application that can't fit in 1000x700 window. we can create a 1000x700 image showing only a part of the window ?

fifth:

  • App Name: No weird formatting, punctuation, lowercase, etc.

i suggest to create an exception of app that use exact the same name of the upstream. i'm thinking on some games that has "weird names" itself, volontary (ex: "ET: Legacy")

sixst:

  • Summary: Understandable for a non-technical person
  • Summary: Easy understandable for target person
@bragefuglseth
Copy link
Contributor

bragefuglseth commented Dec 29, 2024

I'm not involved in work on the guidelines myself, but I currently have 2 of my own apps on Flathub, both of which pass all the current guidelines. Here are some of my thoughts:

  • App Name: Shorter than 20 characters (25 if exists multiple flavor of same app)
  • Summary: Shorter than 35 characters (45 if exists multiple flavor of same app)

If the name/summary limits are increased, I don't think it would make sense to do that for only a specific group of apps. It would require accomodations to make longer strings look great in all places where featured apps are displayed anyways, and at that point other apps might as well be allowed to have as longer names and summaries too.

With that said, I'd only agree with a decision like this myself if more explicit restrictions on name contents were introduced as well, such as disqualifying names that unnecessarily contain the name of the developer/vendor (e.g. Microsoft Edge), to get as few long app names as possible. Long app names tend to simply not look that great anywhere.

I'll also add that if multiple "flavors" are actually warranted for an app, I think those should be different enough from each other to not need an increased summary length.

it's not clear if we can crop the window to show some particular detail. it can be usefull for complex application that can't fit in 1000x700 window. we can create a 1000x700 image showing only a part of the window ?

This seems like a common problem among more complex apps, and I think it might make sense to allow cropped images as long as the cropping serves a purpose, the screenshots are pure/unaltered, and the "main" screenshots are still of holistic windows. Cropping definitely can't be allowed for screenshots that are to be used in banners.

  • Summary: Easy understandable for target person

One has to consider that if an app is featured, it will likely be viewed by a much larger group of people than just a diffuse "target audience". If an app wants to convey its purpose in a way that's only understandable for a very specific audience, being featured might not really be what it's looking for. However, for apps that actually center around a specific external technology or project, I think it could make sense to allow mentioning that as long as:

  • the name of said external project also follows Flathub's naming guidelines (i.e. to avoid super ugly and long acronyms)
  • the external project is directly related to the actual purpose of the app and is not an implementation detail. (so "Build software with Python" would be ok for a Python-focused IDE, but any summary containing "written in Python" would not. In the same sense, a smart home connectivity app should say what it actually does instead of mentioning the framework or protocols it's based on)

My sentiment in all discussions that involve "opening up" some of the quality guidelines, is that they are mainly in place to make Flathub's homepage look neat, and to showcase apps that have put in an conscious effort throughout both the development and branding process to look presentable and appealing in an app store. If an app, even an upstream that the packager can't control, has a long and unconventionally formatted name, a low-quality icon, and an interface that is impossible to take a single good, holistic screenshot of, as well as being impossible to summarize in a brief, non-technical way, I think it's completely okay to say that featuring it would go against the purpose of having featured apps in the first place, and be done with it. The app can still exist on Flathub, after all.

@xanscale
Copy link
Author

reply by points:

  1. i don't think short name are for tecnical reason (space) but exactly for "Long app names tend to simply not look that great anywhere". keep base guideline short and add some exceptions (like flavor) is for minimize number of long app name
  2. about flavor differences: sometimes it's just the licence, like community/paid version, with the paid with just some extra functionalities
  3. about understandable summary, i mean something like "Great IDE for Java" is perfect for any possible target of the app, but not understandable for common user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants