Mark common applications? (previously named "What is common?")

I wonder who defines what is a "common" application. Just one random (potentially bad) example: Among the pkgstats users the package "freetalk" is installed by 1.17%. Is that common? If it is, why is another jabber client named "kadu" not common (1.53%)? Of course, I do not know how representative these statistics are. But could they be better than adding everything someone thinks is common (or wants to be common)?

One way could be to list all applications in a category that are installed by more than 10% of pkgstats users. If this yields less than 3 applications, list the 3 most common ones regardless of their installation percentage. --Markus00000 09:19, 16 October 2011 (EDT)

Another simpler way would be moving the article to List of Applications, which already redirects here anyway. You can add kadu if you want, I don't see any harm in having a page that tries to group packages/applications by genre independently from their usage share. -- Kynikos 07:39, 17 October 2011 (EDT)

Personally, I would find a page listing only the most commonly used applications for each category, split into graphical and console applications, very helpful. As we all use the same distribution, I found that applications recommendations from Arch users where usually exactly what I was looking for (e.g. Light and Fast Award). Conversely, a long page listing many applications seems to me no more useful than a web or pacman search. --Markus00000 08:22, 17 October 2011 (EDT)

I'm quite sure that if we do it that way, a discussion like this will be created once a week or so :) You are supposed to decide by yourself what's the best application that you want to use for a particular purpose, not basing your decision on its "popularity" (we'd all be using windoze that way :P ), but reading reviews and user opinions, official documentation and yes, even trying many apps before finding the "right" one.

By listing only some "common" applications, using a filter that would always be in dispute, we would bias the preference of users, that's the main reason I don't support such a method. What's more, it'd be much harder for new applications to be noted and increase their popularity.

About the pacman search argument, AFAIK the database doesn't store a "type" property for packages.

Then the obvious solution is to make List of Applications list packages, and, in case I or anybody else cares to create it, Common Applications list the most common applications based on objective pkgstats statistics. Sounds good? --Markus00000 09:10, 17 October 2011 (EDT)

Status is open for discussion. My opinion is still the one expressed in my other replies: I'm against any form of filtering, I'm in favour of using marks based on objective (read "indisputable") rules. If some sections become too long they can be moved to other pages or subpages like Games or Backup Programs (I'd prefer subpages, so these two examples should be moved). I'm in favour of renaming the page List of applications.

+1 for renaming the page List of applications, I'm fine with the marks. What would the objective rules be? -- Karol 08:05, 26 December 2011 (EST)

Good, the rule for discerning between common and uncommon apps may be based on pkgstats as proposed initially by Markus00000, I'd say an application is common when it's installed by more than min(10, N*0.75)% of pkgstats users, where N is the percentage of installation of the most common application in the category. (I hope it's clear, may need to be rephrased, values 10 and 0.75 may be adjusted)

We may also find a rule for marking lightweight applications, any ideas?

Then we should also find users interested in actually do the marking thing, otherwise if we just end up having 3 or 4 marked entries in the whole article it may not be worth it.

I don't think that determining if some app is lightweight/common or not can be done in the Wiki. There is simply no objective criteria of this. Is dwm common? Probably less than 1% of GNU/Linux users run it, but among KISS-aware geeks it is very common. Is Opera common enough to be listed? Is Firefox lightweight? Is emacs lightweight? And after such questions.. THE EPIC FLAME BEGINS! To avoid flames and Wiki-wars, we should not start such classification in the first place. Is not it user's deal – to determine which app is lightweight and which has the best userbase? IMHO the only thing one can do is to write proper application description and (if enough spare time is present) create article about that app. The rest is for the readers.

PS "List of applications" is proper title but I'd suggest "Recommended applications" as more honest.

Lightweight Applications

What happened to the list of lightweight applications that used to be on the wiki? Now it redirects here. That list was useful for people (such as myself) who don't want (or can't run) heavyweight apps requiring KDE or Gnome libs. Now we have to pick through the list and find out for ouerselves whether it's light or heavy? How is that an improvement?

You can search the page for the word 'lightweight' and you will find e.g. "zathura — Another lightweight PDF viewer similar to apvlv, only lighter".

If we decide to implement the idea above to mark the most common apps with a special symbol, we can do the same with lightweight apps, provided we find an objective definition of "lightweight". -- Kynikos 11:19, 30 October 2011 (EDT)

Not sure if that's what you meant in 5.1, but I disagree if you want to merge AUR_Helpers with Pacman_GUI_Frontends, I think they should be kept separate. -- Karol 07:47, 3 January 2012 (EST)

Re: (I needed a non-indented line here...)

Do you mean you'd use GentooWiki/Wikipedia links in place of the current redlinks? EDIT: fixed directly in the original post I don't have a position yet on this idea, redlinks can have their own purpose too, for example they feed Special:WantedPages even if it's broken by the i18n template currently... More opinions needed!

Remove unless they can be fixed somehow EDIT: fixed directly in the original post

Yes please

Why not

This is the most controversial point: what do you mean exactly? You're talking about "separate articles" and then about merging some others, it's not very clear at the moment EDIT: the original post has been modified I would move to separate articles (better subpages) only the sections that have more than N entries (and discuss what the value of N can be)

Makes sense now

Also this one seems a good idea

Please let's discuss this one later, otherwise we are having too many irons in the fire. Also I'd like you to explain better why you moved Desktop Environment to X Desktop Environment. I consider it a superfluous change and would like to restore the previous title. The same goes for Window Manager and X Window Manager. Please discuss this kind of changes before performing them. More opinions are welcome.

Reposting whole lists wastes so much horizontal place :_; Ok, I will care more about readability.

>> why you moved...

Thanks for discussing this. I guess, I should explain:

curently this change may look as a bit superfluous as X is the only base of all major DEs, but this is subject to change due to Wayland development. There are also surprisingly huge number of Arch users experimenting with lightweight WMs and even framebuffer-based systems. Can such environments be considered "Desktop"? Without doubt, yes. Anyway, until Desktop Environment's contents change to something else than redirect to X Desktop Environment it is not so big deal, is it? And yes, in context of written, Window Manager currently describes X Window Managers, not, for example, ones compatible with Wayland or even console dvtm. --AlexanderR 21:12, 15 January 2012 (EST)

I do not think it's fair to change "desktop environments" in "X dekstop environments", because the page on the desktop environments must describe the various projects that are by definition "desktop environments", not because run under X or "Wayland." The same goes for "window manager". I think that this division only creates confusion and is redundant. Within the same article you can mention if a DE runs or less on "Wayland", and how to make it work must be described on the page of DE. Otherwise you risk having in the future some wiki, "Wayland dekstop environments", "X dekstop environments", "X kde", "Wayland KDE", etc. In "desktop environments" there is a table # Desktop_Environment Comparison_of_desktop_environments, add here, a voice on the support or not to X, Wayland, etc.Veleno 06:26, 16 January 2012 (EST)

>> ...must describe the various projects that are by definition "desktop environments"

Can you please specify this "definition"? The one that is currently present in Desktop_Environment is almost incorrect and relates to classic X-based DEs only.

There are already Wayland article with explicit instructions for kwin... Can it be considered the first sign of danger :) ? --AlexanderR 08:00, 16 January 2012 (EST)

First thing I admit it's not easy to follow this discussion and your edits, AlexanderR, but I also have to say that the idea of Template:Common Applications navigation is quite brilliant ^^ I liked it. However, please, I wouldn't like to repeat myself, do not edit your posts, just add new replies or even consider creating new discussions, like for all those News in the list. I'd like to ask you to remove the new additions to your old post and move them to a new discussion or even some subdiscussions (subsections) of this very discussion.

About the X/Wayland problem, I'd like not to "cross our bridges before coming to them": Wayland is still a marginal and experimental project, when we will start having more Wayland-related articles and some kind of conflict with X-related articles will actually rise we will change the titles appropriately. Until then, however, I'd stick with the previous policy where X is assumed unless stated otherwise.

Sorry for this – I copied last questions to new discussions (and thanks for mentioning subsections).

>> I'd like not to "cross our bridges before coming to them"

Ok, I agree, such edits should at least follow improvements in articles instead of preceding them. I undone both. I guess, this thread can be safely removed now.

Before creating too many Common Applications subpages and navigation templates, perhaps we should first settle #Improving the title? -- pointone 23:04, 16 January 2012 (EST)

(Reopened) I guess we're too late for that... :) That would have been better indeed, I've replied to your answer to #Improving the title, let's make a decision and do the rename soon. -- Kynikos 07:31, 17 January 2012 (EST)

I added the "Pager" entry there quite recently as a replacement for the most article, which was just 1 line of text. Note that most is not a core application, I don't know if we should have a "Pagers" section in Common Applications... thoughts? -- Kynikos 07:49, 17 January 2012 (EST)

Classification troubles

Can "CD/DVD Burning Tools" be considered part of "Multimedia"?
Should "Screen Capture" section be part of "Utilities" or "Multimedia"? --AlexanderR 21:10, 16 January 2012 (EST)

Eh I'm afraid we'll just have to establish a convention: I'd say Burning tools in Multimedia and Screen Capture in Utilities? Let's wait for more opinions. -- Kynikos 07:53, 17 January 2012 (EST)

Split up completely?

Just wondering if it would be better to completely split the article up into separate articles, rather than transcluding everything back in as templates. Perhaps just include links and a brief summary of each category in the top-level page, maybe something along the lines of:

Smaller individual pages would be nicer, because often I’m only interested in programs for a specific application, such as (in the past) Science#Electronics, and Multimedia#GUI players (audio). Even using the TOC, I think currently it’s too easy to get lost or overwhelmed. Vadmium 00:18, 26 January 2012 (EST).

I think the main problem here is that if I'm looking for a particular subcategory I have to guess under which main category it can be, while currently, with the comprehensive ToC, that task is easier. Possible compromise: maintain a "manual" Table of Contents in the top-level page, with links to the various subpages/subsections. Let's hear more opinions. -- Kynikos 07:53, 26 January 2012 (EST)

See also visibility

Does somebody have any idea on how to improve the visibility of the See also section? -- Kynikos 07:13, 23 January 2012 (EST)

Its probably not in good style, but could we add an article overview, and have an article summary section containing the see also links?--Leocp1 16:59, 23 January 2012 (EST)

@Leocp1 What links are you talking about? Wiki links already should be covered by Template:Article_summary_wiki), among others I'd prefer to see only important ones (like links to software home page, documentation, own wiki etc) included included in the template. --AlexanderR 19:11, 23 January 2012 (EST)

I've written a summary in the subsection below and added some other ideas: currently I think solution 4 may be the tidiest and best looking, otherwise I'd try solution 1 as a second choice. Please add your opinions there so we can make a better decision.

@AlexanderR We're talking about the See also links at the bottom of the article, not the links specific to each application, which should stay in the proper App template and/or the related wiki article (I'm not sure if that's what you meant).

Who in the world uses this links at all? Wikipedia does not have any links at the bottom of articles except proofs of written or ones in categories templates. We do not provide proofs.. Or do we? And it would be great to see statistics of clicks on such links... --AlexanderR 08:01, 24 January 2012 (EST)

Not sure if I'm on the same page as you, but many Wikipedia articles have 'External links' section at the bottom, below the references and above the 'Related articles' part. Have a look at e.g. http://en.wikipedia.org/wiki/Uefi article. It has 'See also', 'References' and 'External links' sections. -- Karol 08:43, 24 January 2012 (EST)

Ideas so far

There's little room for long URLs and/or descriptions, unless we want to see ugly line wrapping. -- Kynikos 07:38, 24 January 2012 (EST)

It's possible that in the future the style for article summaries will be reformed not to allow external links anymore, requiring them to be in See also sections only. -- Kynikos 07:38, 24 January 2012 (EST)

No problems with line wrapping. --AlexanderR 23:48, 3 February 2012 (EST)

In many articles links to site/Wikipedia/etc. are already located in random places in text. Placing them all into single template at the top will hardly make "See also" section less visible than now. --AlexanderR 23:48, 3 February 2012 (EST)

CONS:

Same as 1.

The See also section will be even more "buried" at the bottom of the article, becoming practically useless. -- Kynikos 07:38, 24 January 2012 (EST)

Find a new name instead of "See also", move the section at the top, as the first section (and change its layout, e.g. use 2 columns?). -- Kynikos 07:38, 24 January 2012 (EST)

PROS:

Links are immediately accessible and there's room for long URLs and descriptions. -- Kynikos 07:38, 24 January 2012 (EST)

CONS:

Incosistent with the other articles, may look ugly. -- Kynikos 07:38, 24 January 2012 (EST)

Link to #See also from the introduction, with a sentence that enhances its visibility. -- Kynikos 07:38, 24 January 2012 (EST)

Well yes, it would be better if they were merged here. About making a rule, maybe it should concern only subpages that are included in a single main page, just like List of Applications and Beginners' Guide (and do we have any other examples? I can't think of any right now...). -- Kynikos (talk) 11:10, 5 August 2013 (UTC)

Good points... I'll move the discussions here and add a note to start new discussions here. When/if there are more pages like this, I think some rule should be made. -- Lahwaacz (talk) 13:18, 5 August 2013 (UTC)