Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://extensionworkshop.com/documentation/develop/create-an-appealing-listing/ below:

Create an appealing listing | Firefox Extension Workshop

There are two essential steps to getting people to use your add-on: they need to discover your add-on and open the listing page, then the listing page needs to encourage them to click the Add to Firefox button. The content you add to a listing is therefore vital: from making effective use of keywords in your descriptions, to get visibility in external search engine results, through having an icon that attracts a user’s attention from a category list, to screenshots that show how useful your add-on is.

So, let us look at some of the ways you can encourage users to get to your listing page and, once there, install your add-on.

You want your add-on’s name to be unique and descriptive, so it gives the user a good indication of what your add-on does. If your add-on does something similar to existing add-ons—a note taking app for example—don’t be tempted to call your add-on “Barbara” to differentiate it. Rather, look for a descriptive name that is not in use, such as “Best notes”, “Fast notes”, or similar.

Another advantage of using a unique name is that you also get a unique slug on addons.mozilla.org (commonly referred to as AMO) that matches your add-on name.

Your add-on’s icon could be as important, if not more so, as your add-on’s name. An eye-catching icon can draw users to your add-on in a category list or search. Where possible, make the icon relevant to your add-on’s function—for example, a notepad for a notes application. Also, unless it is part of a recognizable brand, do not include words or letters in your icon: you will be using the same icon across all locales, so words or letters may not translate well. You can load icons at two resolutions—32x32 and 64x64—in either PNG or JPEG format, but consider using SVG or similar vector format for the icon’s source, to get optimum scaling.

Before writing your add-on’s summary and description, or adding version details, think about the keywords someone might use to search for an add-on such as yours. You can add these keywords as tags to your add-on listing (in the Basic Information section). With careful use in your summary, description, and version details, the keywords will also help users discover your add-on through web searches. And, when you use keywords in your text, remember to keep their use natural: forcing keywords in won’t help readability nor will it improve search rankings.

The summary description for your add-on is limited to 250 characters, but do not consider it a challenge to use all the available characters. Keep your summary as short as possible while highlighting the key features of your add-on and how they will benefit the user. Be direct and to-the-point.

There isn’t a practical limit to the number of screenshots you can include in an add-on’s listing, but don’t keep adding them: make sure each screenshot shows a key feature of your add-on. Do not be afraid to annotate your screenshots. However, you can only load one set of screenshots, although you can localize their descriptions. So, annotate to highlight features but explain the annotations in text, not on the screenshot, and avoid adding text to the images.

We recommended that you capture images that are 1280x800px (the maximum image display size). For other image sizes, we recommend using the 1.6:1 ratio.

You also have the option to reorder your screenshots, so make sure they tell a story about your add-on’s features. This will help users gain a better understanding of how your add-on will work for them.

While the add-on summary is limited to 250 characters, you are not practically limited when it comes to the add-on’s description and version details. However, don’t think you need to use this freedom to write a novel.

Most users will take only a few seconds to scan your listing to determine if your add-on is of interest to them. So, make the opening comments in the description impactful. Then make sure the remainder of the descriptions says what needs to be said, but no more. Also, use the available HTML formatting to make your copy easier to scan. For example, list key features in bullets and highlight keywords or phrases that describe your add-on’s features.

As with the summary, remember the key is to tell the user why your add-on will matter to them: do not just describe features, explain the benefits to the user.

Similarly, when you are adding version details, be crisp and to-the-point. Make sure you highlight fixes to any issues users have raised or improvements implemented from user suggestions. If prospective users see that you listen, they will be more inclined to try your add-on.

If your extension is developed using WebExtension APIs, we offer comprehensive support for internationalizing your extension, using the i18n API, so you can add translations and localize your extension. You also have the option to localize almost all the text content of your add-on’s listing, including its name.

You will want to add a localized listing for each language your add-on supports. However, even if your add-on does not offer a wide selection of localized versions, localizing the listing content can help make your add-on more accessible to users around the world.

Also, remember to set the most appropriate default locale, so that users browsing in languages you have not localized to get the best impression of your add-on.

If your add-on is an experiment, flag this when you submit it to AMO. While doing so will reduce the add-on’s visibility on AMO, it is important to make sure that users are aware, so their expectations are appropriate. If you do not mark an experimental add-on, you could end up with poor reviews that your add-on does not deserve, and once you have a poor rating and poor reviews, it can take a lot of work to build a better reputation.

If your add-on does not work on Android be sure to select only Linux, Mac OS, and Windows as the supported platforms. This will avoid issues with users giving poor reviews because your add-on does not work on their platform or Firefox version. For more information on defining version support, if you need to, see the manifest.json browser_specific_settings key.

You can select up to two categories to describe your add-on. Choose carefully to get the best match. However, do not include your add-on in a second category if one will do, as spamming a category could do more harm than good.

Providing support for your add-on gives potential users the assurance that they will be able to get any issues resolved. In your add-on’s listing you can provide details of its homepage, an email address for support, and the address of a support page on your website or the add-on’s website. If you can, provide all three of these. However, as a minimum, consider offering an email address for support.

Your developer profile enables you to provide information about the reasons behind the creation of your add-on and what you plan next for its development. You do not need to create a developer profile, but if you do, as with all other descriptions of your add-on, make comments short and to the point.

If your add-on makes use of personal data, you will need a privacy policy, and you may want or need an end user license agreement. Make sure these are written in plain language, not legalese. Plain language makes these documents accessible to your users and makes it more likely they will install your add-on.

Remember to include the text of your privacy policy and license agreement in your add-on’s listing details, even if you host a copy on your website or in the add-on.

Ratings and reviews are a huge benefit to your add-on, assuming they are good. When you are happy that you have the features and quality needed in your add-on, consider requesting users to complete a review.

However, take care with requesting reviews, here are some guidelines:

• Do not make leaving a review a requirement of accessing features within your add-on.
• Do not repeatedly request the user to provide a review, if they do not want to provide a review nagging them could result in them uninstalling your add-on.
• Do give the user time to learn about and use most of your add-ons features before requesting a review.
• Do not try to influence the user’s review by pre-populating the comments section or selecting a five-star rating.

And, when users suggest improvements or highlight issues in the reviews, use the reply feature to acknowledge their feedback.

Some fields in your add-on's listing support a limited set of Markdown.

This is a blockquote.

• List item

1. List item

• Where several people have helped in writing the add-on, make sure they are listed as Authors.
• Keep any requests for contributions appropriate.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3