2,751
edits
Changes
Jump to navigation
Jump to search
m
Activity Library/Editors/Featured and Recommended (view source)
Revision as of 13:34, 18 March 2009
, 13:34, 18 March 2009initial content
{{draft}}
= Featured Activities =
* Featured Activities are activities that get rotated into one of three slots on the [https://activities.sugarlabs.org/en-US/sugar/ main page of ASLO]
* Ideally, the types of activities to be featured should be already on the category-recommended list. By also being on the recommended list, the Sugar activities's manager can help pull them using the API and offer them.
* Expectations should be set that participation in the Featured Activities list will only be temporary
* In order to prevent staleness
** We should rotate the list every 3-4 weeks
** With 3 slots available, the following shows the number of unique pages that can be generated with the number of featured add-ons.
*** (5,3)=10, (6,3)=20, (7,3)=35, (8,3)=56, (9,3)=84, (10,3)=120
** Recognize that with a fewer number (e.g. 5) of add-ons on the featured list, you will get lots of repetition, seeing the same ones being promoted every time.
** At minimum, we should strive to have at least 10 featured activities
* When designing a list, we should try to sample from the various categories that ASLO has. Currently ASLO has about 10 categories. Ideally, we show not be showing more than five from each category.
* Sugar Labs can potentially use "featured" as a way to help promote selected partner activities (even if they are not on the Reco Lists)... this is not ideal. It's better to be organic, become Recommended first and let the community and users drive popularity.
* In order to not surprise the activity developers/partner, we should try to notify them before we put them up there since they will likely get a surge in activity downloads - they may need to prep servers to handle load, etc... It's good to notify.
* We should keep a spreadsheet/record of what was the feature list at every point in time
* We should create "events" in the developer control panel for the featured activity and watch the downloads/active usage charts
* We should review the performance of activities and if a featured activity is not performing well, perhaps the description/image needs to be modified.
* We should gather some stats about how well activities perform when they are featured versus recommended versus simply public.
* How do you become a featured activities?
** In general, Sugar Labs's policy should be to rotate activities from the Recommended List onto the featured list. Everyone should get a fair chance!
** Based on Activity Team discretion, it may decide to feature particular activity.
** Apply by emailing aslo-admins@sugarlabs.org
** Featured activities must be hosted on ASLO
* Technically, how do you make an activity featured?
** Changing Featured Activities requires Admin Group access to ALOO.
** Use the Admin Tools::Feature Manager to decide what is on that list
*** If added to the "Unspecified" list, then it is added to a global list (essentially adding it to all locales)
*** If added to the local-specific list, then the activity will be rotated in for that locale only.
= Recommended Lists =
* Recommended List Activities are activities that appear on:
** One of the slots in the ALSO category landing page
** The Recommended List Page
** The default view in the "Get Activities" panel in the Sugar Activities manager
* Recommended List Activities get rotated into one of 2 slots on the [https://activities.sugarlabs.org/en-US/fsugar/browse/type:1/cat:22 category landing page of ASLO]
* All recommended List Activities get listed on the [https://activities.sugarlabs.org/en-US/sugar/recommended ASLO recommended list page]
* If a user has already installed a Recommended Activity into the Activities Manager, it will not be displayed.
* If a Recommended Activity is not compatible, it will not be displayed in the Activities Manager
* Recommended lists are locale and category-specific
* Although activities can be members of multiple categories, they should only be considered recommended in a single category for each application they support. We don't want activities spamming the various Reco Lists in lots of categories.
* How do you become a recommended activity?
** See [https://activities.sugarlabs.org/en-US/sugar/pages/policy ASL Policy Pages] - last question
** ALSO is meant to be a community oriented site. With editors who are closely monitoring additions to the site. Their expertise is called upon for selecting the recommended activities.
** Activity authors should apply by emailing aslo-editors@sugarlabs.org and provide the requested info
** Based on Sugar Labs community discretion, it may decide to recommend particular activities.
** Recommended activites may possibly not be hosted on ASLO (ie, they have stub ASLO entries and are hosted at another web site). These must be closely monitored for changes. We currently don't have this capability in ASLO but may add it in the future.
* What is the mandatory checklist for deciding whether to make something recommended?
** Review the application, ensure it answers some of the requested basics
** Install the atctiviy, does it work as expected?
** Read the feedback on ASLO
** Do a Google search and see feedback, blog posts, testimonials, etc...
** Does it have funky licensing (e.g. hampered functionality, trialware and then expires)? (nix it if it does)
** Does it have dependent software? (nix it if it does)
** Check the error console, does it general errors. Content warning are OK.
** Is it irritating? Does it ask for money on every usage? Does it popup windows all over the place?
** Judgement call: is it generally useful for the broad Sugar audience?
* Rotating the Reco List
** When should something be removed from the activities list?
*** If there isn't active development or releases within the last 6-8 months
*** If it's functionally broken or is causing errors in the console
*** If it violates ASLO policy on privacy, piracy, obscenity, etc...
*** If there are more interesting activities that should be shown and we don't want to grow the list too large
** Review the list of top downloaded & most actively used activities and see if anything new is coming up
* Technically, how do you make an activities recommended?
** Changing the Reco List Activities requires Editor access to ASLO.
** Use the Editor Tools::Feature Manager to decide what is on that list
*** Find the activity type and category
*** Start typing the name of the activity or use the [1224] format
*** If the next field is blank, it means add it for all locales. Otherwise provide a comma-separated list of locale names.
= Building Recommendation Lists =
If I were to design the idea recommendation list, I would consider whether:
* The add-ons are generally compatible with each other
* Not all of them are site-specific
* Doesn't create a weird first-run experience when more than 2/3 are chosen
* Represents a sample of the variety of add-ons that are available
* Represents a cross-section of things that people do on the Internet, e.g. social networking, chat, VOIP, video, commerce, information retrieval, music, info/data organization, etc...
What are some of the ideal criteria for deciding if something should be recommended:
* Has it been marked as a "favorite" by users?
* Popularity based on AMO or other locations downloads, already in the hands of lots of users, mileage, tried and tested (at least 20,000 downloads?)
* "perceived as useful", "well maintained" and "well tested".
* Helps demonstrate an interesting browsing experience
* Quality, works as expected, proven
* Effect on performance (startup time, rendering time, UI zippiness)
* Effect on memory usage (static and over time, no leaks)
* Free of security holes
* Has good feedback from reviewers and end users
* Doesn't degenerate or severely affect the core Firefox user experience
* Appropriate for New-to-Firefox Users (new demographic)
* Demonstrates interesting capabilities
* Brand compatible
* Not severely incompatible with privacy policy/No spyware
* Useful for a general populace
* Compatibility with current Firefox release (and beta versions)
* Documentation/associated content (e.g. support on relevant site, mktg, help info, etc…)
* Licensing - is it trialware?, MPL, etc…
* Hurdles to get going: does it require a new login? Or extra client software?
* Compatibility with other extensions
* Support for addon by developer, forums, docs, etc…
= Trusted Add-on =
* What is a trusted add-on?
** A trusted add-on will allow subsequent updates to be automatically pushed public without getting sandbox'ed. Being trusted means that the add-on will not be queued for review by an AMO editor.
** AMO has a small, select group of addons on the trusted list.
* How do you become a trusted add-on?
** Add-on author should drop an email to amo-editors@mozilla.org explaining why they need trusted status
* What is the criteria for becoming a trusted add-on?
** Is the add-on of high quality with its own development branch and low update frequency?
** Do the developers seem to care about security?
** Do the developers want to fix bugs fast and have demonstrated that they've done that?
** Non criteria:
*** reduce workload for AMO Editors
*** Limited audience for extensions, small group of editors
= Featured Activities =
* Featured Activities are activities that get rotated into one of three slots on the [https://activities.sugarlabs.org/en-US/sugar/ main page of ASLO]
* Ideally, the types of activities to be featured should be already on the category-recommended list. By also being on the recommended list, the Sugar activities's manager can help pull them using the API and offer them.
* Expectations should be set that participation in the Featured Activities list will only be temporary
* In order to prevent staleness
** We should rotate the list every 3-4 weeks
** With 3 slots available, the following shows the number of unique pages that can be generated with the number of featured add-ons.
*** (5,3)=10, (6,3)=20, (7,3)=35, (8,3)=56, (9,3)=84, (10,3)=120
** Recognize that with a fewer number (e.g. 5) of add-ons on the featured list, you will get lots of repetition, seeing the same ones being promoted every time.
** At minimum, we should strive to have at least 10 featured activities
* When designing a list, we should try to sample from the various categories that ASLO has. Currently ASLO has about 10 categories. Ideally, we show not be showing more than five from each category.
* Sugar Labs can potentially use "featured" as a way to help promote selected partner activities (even if they are not on the Reco Lists)... this is not ideal. It's better to be organic, become Recommended first and let the community and users drive popularity.
* In order to not surprise the activity developers/partner, we should try to notify them before we put them up there since they will likely get a surge in activity downloads - they may need to prep servers to handle load, etc... It's good to notify.
* We should keep a spreadsheet/record of what was the feature list at every point in time
* We should create "events" in the developer control panel for the featured activity and watch the downloads/active usage charts
* We should review the performance of activities and if a featured activity is not performing well, perhaps the description/image needs to be modified.
* We should gather some stats about how well activities perform when they are featured versus recommended versus simply public.
* How do you become a featured activities?
** In general, Sugar Labs's policy should be to rotate activities from the Recommended List onto the featured list. Everyone should get a fair chance!
** Based on Activity Team discretion, it may decide to feature particular activity.
** Apply by emailing aslo-admins@sugarlabs.org
** Featured activities must be hosted on ASLO
* Technically, how do you make an activity featured?
** Changing Featured Activities requires Admin Group access to ALOO.
** Use the Admin Tools::Feature Manager to decide what is on that list
*** If added to the "Unspecified" list, then it is added to a global list (essentially adding it to all locales)
*** If added to the local-specific list, then the activity will be rotated in for that locale only.
= Recommended Lists =
* Recommended List Activities are activities that appear on:
** One of the slots in the ALSO category landing page
** The Recommended List Page
** The default view in the "Get Activities" panel in the Sugar Activities manager
* Recommended List Activities get rotated into one of 2 slots on the [https://activities.sugarlabs.org/en-US/fsugar/browse/type:1/cat:22 category landing page of ASLO]
* All recommended List Activities get listed on the [https://activities.sugarlabs.org/en-US/sugar/recommended ASLO recommended list page]
* If a user has already installed a Recommended Activity into the Activities Manager, it will not be displayed.
* If a Recommended Activity is not compatible, it will not be displayed in the Activities Manager
* Recommended lists are locale and category-specific
* Although activities can be members of multiple categories, they should only be considered recommended in a single category for each application they support. We don't want activities spamming the various Reco Lists in lots of categories.
* How do you become a recommended activity?
** See [https://activities.sugarlabs.org/en-US/sugar/pages/policy ASL Policy Pages] - last question
** ALSO is meant to be a community oriented site. With editors who are closely monitoring additions to the site. Their expertise is called upon for selecting the recommended activities.
** Activity authors should apply by emailing aslo-editors@sugarlabs.org and provide the requested info
** Based on Sugar Labs community discretion, it may decide to recommend particular activities.
** Recommended activites may possibly not be hosted on ASLO (ie, they have stub ASLO entries and are hosted at another web site). These must be closely monitored for changes. We currently don't have this capability in ASLO but may add it in the future.
* What is the mandatory checklist for deciding whether to make something recommended?
** Review the application, ensure it answers some of the requested basics
** Install the atctiviy, does it work as expected?
** Read the feedback on ASLO
** Do a Google search and see feedback, blog posts, testimonials, etc...
** Does it have funky licensing (e.g. hampered functionality, trialware and then expires)? (nix it if it does)
** Does it have dependent software? (nix it if it does)
** Check the error console, does it general errors. Content warning are OK.
** Is it irritating? Does it ask for money on every usage? Does it popup windows all over the place?
** Judgement call: is it generally useful for the broad Sugar audience?
* Rotating the Reco List
** When should something be removed from the activities list?
*** If there isn't active development or releases within the last 6-8 months
*** If it's functionally broken or is causing errors in the console
*** If it violates ASLO policy on privacy, piracy, obscenity, etc...
*** If there are more interesting activities that should be shown and we don't want to grow the list too large
** Review the list of top downloaded & most actively used activities and see if anything new is coming up
* Technically, how do you make an activities recommended?
** Changing the Reco List Activities requires Editor access to ASLO.
** Use the Editor Tools::Feature Manager to decide what is on that list
*** Find the activity type and category
*** Start typing the name of the activity or use the [1224] format
*** If the next field is blank, it means add it for all locales. Otherwise provide a comma-separated list of locale names.
= Building Recommendation Lists =
If I were to design the idea recommendation list, I would consider whether:
* The add-ons are generally compatible with each other
* Not all of them are site-specific
* Doesn't create a weird first-run experience when more than 2/3 are chosen
* Represents a sample of the variety of add-ons that are available
* Represents a cross-section of things that people do on the Internet, e.g. social networking, chat, VOIP, video, commerce, information retrieval, music, info/data organization, etc...
What are some of the ideal criteria for deciding if something should be recommended:
* Has it been marked as a "favorite" by users?
* Popularity based on AMO or other locations downloads, already in the hands of lots of users, mileage, tried and tested (at least 20,000 downloads?)
* "perceived as useful", "well maintained" and "well tested".
* Helps demonstrate an interesting browsing experience
* Quality, works as expected, proven
* Effect on performance (startup time, rendering time, UI zippiness)
* Effect on memory usage (static and over time, no leaks)
* Free of security holes
* Has good feedback from reviewers and end users
* Doesn't degenerate or severely affect the core Firefox user experience
* Appropriate for New-to-Firefox Users (new demographic)
* Demonstrates interesting capabilities
* Brand compatible
* Not severely incompatible with privacy policy/No spyware
* Useful for a general populace
* Compatibility with current Firefox release (and beta versions)
* Documentation/associated content (e.g. support on relevant site, mktg, help info, etc…)
* Licensing - is it trialware?, MPL, etc…
* Hurdles to get going: does it require a new login? Or extra client software?
* Compatibility with other extensions
* Support for addon by developer, forums, docs, etc…
= Trusted Add-on =
* What is a trusted add-on?
** A trusted add-on will allow subsequent updates to be automatically pushed public without getting sandbox'ed. Being trusted means that the add-on will not be queued for review by an AMO editor.
** AMO has a small, select group of addons on the trusted list.
* How do you become a trusted add-on?
** Add-on author should drop an email to amo-editors@mozilla.org explaining why they need trusted status
* What is the criteria for becoming a trusted add-on?
** Is the add-on of high quality with its own development branch and low update frequency?
** Do the developers seem to care about security?
** Do the developers want to fix bugs fast and have demonstrated that they've done that?
** Non criteria:
*** reduce workload for AMO Editors
*** Limited audience for extensions, small group of editors