#5758 HIGH Never A: Journal can get way to long to be manageable for ordinary users.

[Zarro Boogs per Child]

#5758: Journal can get way to long to be manageable for ordinary users.
------------------------------+---------------------------------------------
 Reporter:  legutierr         |       Owner:  tomeu         
     Type:  defect            |      Status:  new           
 Priority:  high              |   Milestone:  Never Assigned
Component:  journal-activity  |     Version:                
 Keywords:                    |    Verified:  0             
 Blocking:                    |   Blockedby:                
------------------------------+---------------------------------------------
 The Journal is a very convenient and intuitive way to store data that is
 currently (recent days/weeks) relevant to the user.  A couple weeks of
 use, however, can result in a Journal with hundreds or thousands of
 Journal objects (if they are not purged within that time; comments in
 #4365 liken the proliferation of Journal objects to spam), making it
 difficult to use in preserving highly-valued objects for the longer term.

 The search function can help you find something specific, but only if you
 know or remember what you are looking for, and are able to devise the
 right search string.  Individual objects can be "starred", but those
 objects remain mutable when they are re-opened, and may not preserve the
 thing you wanted to preserve originally (think about Browse histories,
 clicking back then opening a new page).  Also, there currently is no way
 of ''only'' looking at starred objects, so to find them you have to scroll
 through a very long list anyway, defeating the purpose of the star
 differentiation.

 In addition, an (ordinary/novice) user doesn't have fine-grained control
 over the system's purge process, and any purge algorithm can potentially
 fail to match-up to a user's expectations, regardless of how well it is
 implemented; see
 http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience/The_Journal#Falloff
 for the requirements of this feature.  A highly-valued object that hasn't
 been touched for a while (like a term-paper from last semester, or an
 important email received last year, or an art project from two years back
 that may be needed for a future portfolio) may be purged accidentally by
 the user, or without the user's knowledge or desire if there is more than
 one user on a system (parents?) and a secondary user is in control when a
 "falloff" confirmation request happens, or if the "falloff" is programmed
 to happen automatically (I actually haven't encountered "falloff"
 confirmation yet).

 One possible solution: creating a second space within the journal for
 highly-valued objects (a Scrapbook?), which would appear as a second tab,
 and would be able to exchange objects with the primary Journal list in a
 manner similar to a USB storage device.  The user would have more control
 over this particular memory space, which would be smaller and easier to
 manage, and objects within this space could be immutable and would avoid
 the purge.  This space could even have an upper limit in terms of
 number/size of objects contained, forcing the user to make prioritization
 decisions.  Multiple alternative spaces could also be available (multiple
 Scrapbooks? one for each grade/course completed? one for websites and one
 for drawings? one for the child, one for the parent?).  And objects
 removed from such a space could be moved to the top of the Journal list to
 prevent accidental deletion of these highly-valued items; permanent
 deletion of highly-valued objects would thus require two separate
 Remove/Erase clicks, which would be good because Journal's "Erase"
 (currently) does not require the user to confirm the deletion before it is
 processed.

-- 
Ticket URL: <http://dev.laptop.org/ticket/5758>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system