Difference between revisions of "User:Alsroot/trash/Activity as a regular Journal Object"
Jump to navigation
Jump to search
| (37 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| − | <noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude | + | <noinclude>{{GoogleTrans-en}}{{TOCright}} |
| − | + | [[Category:FeatureObsoleted|Activity as a regular Journal Object]]</noinclude> | |
| − | |||
| − | |||
| − | |||
| − | |||
== Summary == | == Summary == | ||
| Line 17: | Line 13: | ||
== Current status == | == Current status == | ||
| − | * Targeted release: 0. | + | * Targeted release: 0.88 |
| − | * Last updated: | + | * Last updated: Fri Nov 27 21:28:31 UTC 2009 |
* Percentage of completion: 0% | * Percentage of completion: 0% | ||
== Detailed Description == | == Detailed Description == | ||
| − | '' | + | The major reason for this feature is eliminating confusion when: |
| + | * theres are activities(in Home view) and activity bundles(in Journal) | ||
| + | * user can remove bundle from Journal and activity will be preserved(and vise versa) | ||
| + | * activities could not have bundles in journal(were deleted or its a system wide activity), so user can't copy activity(e.g. to share it via USB stick) using regular shell workflow(Journal) and should be aware of stuff like Terminal | ||
| + | |||
| + | Feature declares: | ||
| + | * every activity which is accessible in sugar has Journal entry | ||
| + | ** for activity came from bundles, entry will have .xo's metadata(timestamp, title etc) | ||
| + | ** for system wide activities, based of /usr directory properties | ||
| + | * there is strong linkage between activity in Home view and journal entry, removing activity in one place, removes it from another | ||
| + | ** in fact, Home view could be treated as a predefined set(with query terms to show only activities) of Journal entries which is viewed in Home [[Features/Journal Plugins|plugin]] | ||
| + | * reflect on system wide activities update, Journal entry's metadata will be changed with keeping only one object per activity | ||
| + | * reflect on uploading to Journal new .xo version of existed activity, could be: | ||
| + | ** follow the same forkflow like with system activities, remove previous .xo from Journal or even do not store uploaded .xo at all, on upload, unzip it to ~/Activities and follow system activities way(entry which represent activity) | ||
| + | ** storing in Journal several versions of the same activity(including system) and on clicking on particular version in Journal, if it its not installed, ask user to upgrade/downgrade activity(to ~/Activities directory) and then start | ||
== Benefit to Sugar == | == Benefit to Sugar == | ||
| − | + | * feature eliminates confusion, e.g. in case of removing activities, when there are activities(in Home view) and .xo bundles in the Journal(that could be absent - .xo deleted, system activity) | |
| + | * let users, that are not experienced in command line applications, copy existed activity(even system) just by draging Journal(or Home) entry to USB source | ||
| + | * since all activities have Journal representation, keep useful information in entry fields(time of installing activity, additional info in description etc.) | ||
| + | * so, it simplifies situation - user all time has in mind that he is working with the same object(activity) but from different views(Home or Journal) | ||
== Scope == | == Scope == | ||
| − | + | ||
| + | * sugar | ||
| + | |||
| + | == UI Design == | ||
| + | |||
| + | Nothing. | ||
== How To Test == | == How To Test == | ||
| Line 45: | Line 63: | ||
== User Experience == | == User Experience == | ||
| − | + | ||
| + | * there is strong linkage between activities in Home view and Journal entries, in fact Home view is just a predefined view [[Features/Journal Plugins|plugin]] to browse activity Journal objects | ||
| + | * user can operate with system activities or activities woth removed .xo bundles(in existed workflow) from Journal, e.g. copy them to USB stick | ||
== Dependencies == | == Dependencies == | ||
| Line 57: | Line 77: | ||
== Documentation == | == Documentation == | ||
| − | * [[Unified Objects]] | + | * [[User:Alsroot/trash/Unified Objects | Unified Objects#Activities_as_Journal_Objects|Unified Objects]] |
| + | * [[Features/Object Bundles]] | ||
| + | * Email threads | ||
| + | ** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg10708.html Activity as a regular Journal Object request for inclusion to 0.88] | ||
| + | ** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg07572.html multiple activity versions installed simultaneously] | ||
| + | ** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06944.html Activity as regular objects proposal] | ||
== Release Notes == | == Release Notes == | ||
| Line 64: | Line 89: | ||
== Comments and Discussion == | == Comments and Discussion == | ||
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --> | * See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --> | ||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 15:05, 5 November 2013
Summary
Use Journal objects to represent activities.
Owner
- Name: Aleksey Lim
- Email: send an email
Current status
- Targeted release: 0.88
- Last updated: Fri Nov 27 21:28:31 UTC 2009
- Percentage of completion: 0%
Detailed Description
The major reason for this feature is eliminating confusion when:
- theres are activities(in Home view) and activity bundles(in Journal)
- user can remove bundle from Journal and activity will be preserved(and vise versa)
- activities could not have bundles in journal(were deleted or its a system wide activity), so user can't copy activity(e.g. to share it via USB stick) using regular shell workflow(Journal) and should be aware of stuff like Terminal
Feature declares:
- every activity which is accessible in sugar has Journal entry
- for activity came from bundles, entry will have .xo's metadata(timestamp, title etc)
- for system wide activities, based of /usr directory properties
- there is strong linkage between activity in Home view and journal entry, removing activity in one place, removes it from another
- in fact, Home view could be treated as a predefined set(with query terms to show only activities) of Journal entries which is viewed in Home plugin
- reflect on system wide activities update, Journal entry's metadata will be changed with keeping only one object per activity
- reflect on uploading to Journal new .xo version of existed activity, could be:
- follow the same forkflow like with system activities, remove previous .xo from Journal or even do not store uploaded .xo at all, on upload, unzip it to ~/Activities and follow system activities way(entry which represent activity)
- storing in Journal several versions of the same activity(including system) and on clicking on particular version in Journal, if it its not installed, ask user to upgrade/downgrade activity(to ~/Activities directory) and then start
Benefit to Sugar
- feature eliminates confusion, e.g. in case of removing activities, when there are activities(in Home view) and .xo bundles in the Journal(that could be absent - .xo deleted, system activity)
- let users, that are not experienced in command line applications, copy existed activity(even system) just by draging Journal(or Home) entry to USB source
- since all activities have Journal representation, keep useful information in entry fields(time of installing activity, additional info in description etc.)
- so, it simplifies situation - user all time has in mind that he is working with the same object(activity) but from different views(Home or Journal)
Scope
- sugar
UI Design
Nothing.
How To Test
This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be.
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
A good "how to test" should answer these four questions:
- What special hardware / data / etc. is needed (if any)?
- How do I prepare my system to test this feature? What packages need to be installed, config files edited, etc.?
- What specific actions do I perform to check that the feature is working like it's supposed to?
- What are the expected results of those actions?
User Experience
- there is strong linkage between activities in Home view and Journal entries, in fact Home view is just a predefined view plugin to browse activity Journal objects
- user can operate with system activities or activities woth removed .xo bundles(in existed workflow) from Journal, e.g. copy them to USB stick
Dependencies
Glucose dependencies.
Contingency Plan
None necessary, revert to previous release behaviour.
Documentation
Release Notes
The Sugar Release Notes inform end-users about what is new in the release. An Example is 0.84/Notes. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.