A conglomeration of responses follow... Also, as a prologue, I will refer occasionally to the designs on the wiki [1], and in particular the 6th slide [2] with respect to the "deletion issue". It's also prudent to note the initial description of the Journal [3] which remains, in nearly all respects, our target.
Oh, and please don't be intimidated by the length; there's a really important chunk at the end... [1] http://wiki.laptop.org/go/Designs [2] http://wiki.laptop.org/go/Designs/Journal#06 [3] http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience/The_Journal On Sun, Aug 3, 2008 at 3:38 PM, Aaron Konstam <[EMAIL PROTECTED]> wrote: > Unless I have missed something that is a very tedious task to lay on > someone using the current GUI interface for erasing journal entries. > Journal entries are added at a steady rate but their removal is a > tedious "one at a time process". I can't imagine child taking the time > to keep these entries erased routinely. Another erasure method is > needed. Wholly agreed. The new Journal design offers checkboxes next to each entry, allowing for multiple selections to be made. Once made, it will also be possible to filter only to selected entries (in case the selection should span large portions of the Journal and be otherwise impossible to view at once), and then act on those entries en masse via a contextual toolbar, in order to delete them, copy them to external storage, or tag them. On Sun, Aug 3, 2008 at 5:29 PM, Bastien <[EMAIL PROTECTED]> wrote: > > In latest joyrides, is there a way to "select all" entries? (C-a) > > This would be useful not only for deleting, but also for copying entries > on the clipboard or on the USB key. There is no select all at present, but once we have the checkbox mechanism described above, I could see this shortcut checking all entries. However, I think that such an action will actually be an edge case once we get everything else right, since copying/deleting every single entry at once probably won't be that common. On Sun, Aug 3, 2008 at 6:03 PM, Albert Cahalan <[EMAIL PROTECTED]> wrote: > I don't even want to look in the journal. Not ever! It's unusable. > It's worse than the worst email inbox nightmare. Nothing has a useful This is something we hope to partially remedy in a future release. Naming clearly took a backseat, in part because it was more important to offer an activity supplied toolbar when opening activity, in part because we don't prompt for a name, and in part due to the journaling auto-save nature of the system. We intend to add a either a) a non-modal alert upon creation of a new instance from scratch (never when resumed), which can be ignored if desired, which prompts for a name (and tags?) or b) a modal alert upon stopping an activity which prompts for name and tags (only if it hasn't been named before). Optionally, the latter could also have an explicit "don't keep" option; this has been hotly debated, but there could be times when it's appropriate to have. > name, the scroll bar doesn't move with my mouse, clicking to mark an Indeed, this sucks. We know it. We want to fix this, and make clean pixel-by-pixel scrolling of entries. This is a really big project (Well, the entire redesign of the Journal is), and it's one we all would like to see happen, but resources haven't yet allowed it. > entry takes many seconds to work (leading me to click again), and This is a known bug. A re-factoring of the Journal GUI code is needed. It's not terribly difficult, but it is invasive, so it wasn't slated for the 8.2.0 release. I agree it's a problem, and I tried myself to fix it before realizing how entangled it is. Note that the star buttons in the list view of Home don't share this problem. > the purely iconic interface is totally incomprehensible. I'd even > prefer the dreadful interface of Macintosh System 1. Well, first I disagree that it's entirely incomprehensible. However, I admit that it could be better. Please refer to the new designs on the wiki, which illustrate a much more friendly approach to looking at recent entries, which includes expandable entries with inline previews of the in-progress activities. We hope that this will make browsing the Journal much much friendlier, without the need to dig into detail view all the time just to figure out which entry is which. On Sun, Aug 3, 2008 at 7:55 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: > I find my way around my 900+ entries just fine. I do agree that a high > percentage of my entries seem to be cruft, but there is a proposed UI > feature that I believe will greatly reduce accidently creating new > journal entries when what was really intended was a resumption of an > earlier entry. The much needed extension of the new Home view to > default to, and display, recent entries for said activity. > > http://wiki.laptop.org/go/Image:Activity_management-07.jpeg > > This combined with a larger Activity name input box (ridiculous small Agreed. There's no excuse. > for no good reason I can fathom), and perhaps even a dialogue to > prompt for a name if one is not set when stopping (though this may > well be annoying unless well planned - a good default name, auto We argued it both ways a few times, which stalled the progress a bit. I lean toward a non-modal alert on creation of a new instance (which can be ignored; would go away after 10 seconds or so). We could have a modal alert on close, which requires one to interact before it goes away. There are pros and cons to both. We could actually do both, as well, and the latter could also have the "don't keep" button on top of that. There are options. We should nail it down for 9.1 and get it done. Pros for non-modal: Can be ignored, names activity before sharing, which gives it meaningful name in Neighborhood Cons for non-modal: Might not know what you're making yet (though, I'd argue, possibility to ignore mitigates this) Pros for modal: Comes at the end, when you know what you've made, could offer a "don't keep" option Cons for modal: Can't be ignored, doesn't name things before sharing > confirm timer, input focus for typing, return key for immediate > acceptance etc). Yes to all of these, regardless of which we choose. >> Clearly, nobody is dogfooding. True and false. We definitely all use XOs a lot. We also use them enough to know their limitations, and to know that for many of us, day to day use for all of our tasks simply isn't practical (yet!). While it's a noble goal, it would also slow us down, even though we're already a team spread thin and with timelines that are near impossible. In other words, we're not ignorant of the problems; I think the Journal is mostly unusable right now too. We acknowledge the deficiencies, and are working hard to fix them. Your constructive feedback and criticism is certainly appreciated. On Sun, Aug 3, 2008 at 11:00 PM, Bastien <[EMAIL PROTECTED]> wrote: > There could be a default (favorite) filter for the journal entries. > I'd suggest something based on time: the more recent the entry, the > more likely it's you want to resume it. > > Such a notion would also nicely combine with the notion of favs in > the home view. And maybe it's not that hard to implement? We do have the star (favorite) buttons in the Journal. Unfortunately, they are just for show at the moment. The new designs aim to make them meaningful. There will be a way to filter to show only starred items, which will do a lot for the "spamming" problem in itself. It should reduce the large number of entries down to those that are specifically useful or meaningful to the laptop's owner, allowing them to search and browse through a subset of all available entries. <important> <!-- This chunk is an extremely relevant portion of my response to the initial problem posed; please read --> Favorites will also be used as a primary heuristic for the forthcoming "auto-deletion" mechanism. Before anyone gets up in arms here, note that I place that term in quotes because we don't actually anticipate deleting anyone's data behind their backs. Instead, we want to support a system which -- based on factors such as favorites, knowledge of current backups, frequency of use, recency of use, file size, intermediate versions, whether or not entries have been named/tagged, etc. -- periodically (when the NAND starts to fill up) /suggests/ to the user a subset of the Journal which could be "safely" erased without much loss. The children (or teachers, or you) then have the opportunity to review the suggestions, uncheck (or favorite) some that they think they really do want to keep, and then press a button to get rid of the rest, cleaning out the "cruft" so to speak. I'd like to think of them more as experiments than "cruft", but oh well. The point is, the Journal should make management simple, and for that matter, one could simply place trust in the Journal eventually, and simply confirm the cleanup operation without second thought. The intention, of course, is that the backups should make most (if not all) of these entries recoverable later. This system is meant to work in tandem with our natural ability to remember (or forget), cleaning out old and less meaningful entries over time, just as we forget about them over time. The human interaction required for the cleanup step can also serve as one last look through the boxes which have sat for too long in a box unlooked at; a time of retrospect, of reviewing progress, etc. I think this will be a natural process of using the laptops, and the Journal, in the future. These boxes then get sent to the attic (the backup), and perhaps eventually, we'll also need a way to clean out the attic and permanently toss things. We'll get there. </important> Thanks for all of your comments, and for reading through my rather lengthy responses. - Eben _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel