Parameters for defining showcase applications in the App Center
I know the app center is quite a bit of time away but Sergey's analysis tool blueprint got me thinking on how to better promote that which is more coherent with the vision of elementary.
A set of rules could be created to determine how close an application is to the eOS *ecosystem*, as to avoid any non empiric approach. What I suggest is creating a list of all the relevant parameters and judging applications against it to see their "elementary index".
Possible parameters include:
-Language/Toolkit used
-Usage of an appmenu
-Usage of granite
-Usage of contractor
-True auto-save
-Proper dock integration
-Proper icons
-Proper buttons and design
-Translatable
-Function and niche (a simple, well done presentation tool in gtk would be something new and quite helpful, another gedit would, while nice, not necessarily be the most needed thing by the ecosystem)
And others. Do add more at the whiteboard.
For example, suppose a developer releases a screenwriting application.
It is written in Vala and uses GTK. +1
It has an appmenu. +1
Doesn't use neither granite nor contractor.
Has true auto-save. +1
Integrates quicklists into the dock. +1
Is missing 128px icons.
Buttons adhere to eOS hig. +1
Translatable through redmine. +1
It is a very niche application, competitors include trelby and scriveneer. As it is, has functions that outperform any gtk competitor. +1
Final elementary index: 7 out of 9
If Shnatsel's analysis tool gets built, it could be used to grade pretty much everything, except for the niche part. But even if the niche part was not evaluated for every single app, there would be enough to grade the applications within a curve, quickly seeing what is best to show and what is best to leave alone.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Danielle Foré
Related branches
Related bugs
Sprints
Whiteboard
I'd rather rely on users' feedback. This is just waaay to complex task to automate, I'm afraid, and I can't see the point of automating it. Not every app needs Contractor or quicklists; there may be exceptions from the HIG; etc. --shnatsel
True - the example was crude as different applications will need and use different things.
The point would be analytical data. A way to gauge developer's preferred toolkits, how extensively granite, contractor and whatnot are being used (and by what kind of application), how translatable software fares against non-translatable, etc...
It would also be a way to manage that which works best and more cohesively with eOS. I understand how gargantuan of a task it would be to automate this (aim for the stars, right?) and so I suggest the next best thing, which would be pretty easy to do. When submitting an application into the app center, allow a developer to fill fields that add such information, such as toolkit, wheter or not the application has an appmenu, if it is translatable, etc...
Doesn't even have to necessarily be mandatory but would already be helpful for when, based on both user feedback and hard data, choices are made as to what to promote on the app center front page.
Or, who knows. Maybe to encourage Qt developers to look at Vala or for people to consider an app menu. This would allow one to see the trend in app development as well. --ottorobba
