Talk:Designs/Journal

Structured Journal-01 view

Would this level of structure be undesirable for the user? --FGrose 17:46, 27 February 2008 (EST)

Our hope here was to humanize it a bit by allowing the actions to read much like sentences. To be honest, I think it's actually a bit more difficult to parse with the staggered approach in this mockup. We considered the possibility of keeping the same list-style as the object view, but thought that this added a meaningful differentiation between the two, and highlighted the "journal" nature. -Eben

I like the idea of naturalizing the reading of the entry, however, it seems that the significant user task in this view is to find a recent activity among the collection of all recent activities. So mental sorting of the displayed activities will be necessary. For example, the user may remember the desired task as one with many collaborators. I find this visual search difficult in the unsorted view, where if I make a mental subview of that dimension, there is an arbitrary chain of XO symbols. --FGrose 16:39, 6 March 2008 (EST)

I troubled with the horizontal staggering as well, but because of the variable length of the opening verbage for each entry, found it as a compromise with the present size and space limitations. Perhaps by adding some very light alternate item background shading or very pale gray horizontal rules, the entries could be kept distinct. Or perhaps displaying the activity icon after the object title would help the readability and spacing. Since the users quickly learn that clicking an activity icon activates it, we could perhaps economize on space and symbols by leaving out the gray circle/white wedge play buttons on this view. (Image:Journal-01b.jpg has the play buttons.) --FGrose 16:39, 6 March 2008 (EST)

We did try rules at one point; we took them out because it made the interface feel a bit rigid. They do, of course, visually break up the entries. I don't find inverting the icon and title to read very naturally. This might be in part because the whole UI is built on the idea that things are represented first by their icon, and secondarily by the text that describes or identifies it. Placing the icon acter the title seems to disconnect the two for me. Another reason, perhaps, is because the icon-then-title ordering is mirrored in the object-centric view. Finally, I should point out that every activity icon will be click-to launch as you mention. The other buttons are still needed, though, as they are the "detail" buttons which reveal the full page entry for the object within the Journal. We're working on another icon for this button that reads less like "play" or "resume" to prevent confusion on this point.

Also, the alternate views right justify the number-like attributes, something that if more generally applied might help synchronize learning and mental maps used in spreadsheet and table building. --FGrose 16:39, 6 March 2008 (EST)

That's an interesting point to bring up. This got me to considering the purpose of the chosen alignments for numbers and dates. With numbers, we align the least significant digits. More importantly, since (assuming fixed with font) digits of corresponding magnitude line up in this approach, comparing the relative size of two right justified numbers is quite intuitive. Dates, on the other hand, usually have their most significant element to the right (at least, the 14 date options in my spreadsheet software all do). This also seems somewhat intuitive: dates usually, unlike numbers, have a fixed number of "digits" (based on the format: for instance dd mm yy). For that reason, they either a) always line up, when displayed in columns, assuming a fixed width format or b) don't at all, due to differences in the length of the strings used to describe a given day or month. For this reason, I think it's more meaningful to compare the most significant digits with dates, since they provide the most accurate measure of the "when" which the date refers to. All of that brings me to say that I actually find right aligning the dates in this context to be misleading, since the most significant portion of the date comes first, and they aren't displayed in a fixed width manner.

Add new entry

Would the user (often) instantiate new activities from the Journal? (since I removed the 'Add new entry' bar.) --FGrose 17:46, 27 February 2008 (EST)

I believe this is a part of the Diary aspect of the Journal, where kids can create entries of pure text ("holidays started today, hooray!"), but I'm not sure how it will work exactly. Will kids be encouraged to create full-blown diary entries through the journal interface, like in a blog? - Eduardo

This is the intent. We feel that adding the ability to create simple text entries direclty within the Journal enhances its function as a personal tool, and could be a useful addition in a classroom context as well, as the teacher may ask the students to write small entries about their learning experiences (or whatever it might be) on a regular basis. -Eben

After checking an entry, loose ability to search

In this design, after checking one entry, a kid can't use the search to find other entries he might want to check, and is limited to scrolling. One thought that comes to mind is if the contextual toolbar was always present in a different tab like in other activities. This of course could create a problem, of a kid checking an entry, then changing the search terms, checking another entry to delete, while forgetting about the previous one. HoboPrimate 19:24, 27 February 2008 (EST)

In the legend for Designs/Journal#06 Eben says the checkbox titlebar button will show a view of all checkmarked items. Perhaps that view ought to be presented as part of a confirmation-of-action dialog. --FGrose 21:19, 27 February 2008 (EST)

Good idea. It is unnecessary for just one item, but multiple of them would be a good idea. On the other hand, I suspect confirmation dialogs aren't very well liked by Eben :).HoboPrimate 05:13, 28 February 2008 (EST)

Yes, this is definitely the intent for actions on multiple selections. -Eben

This is a valid point, and one that crossed my mind when mocking it up. I'm glad it came up for discussion. In fact, much earlier designs of the Journal used tabs in exactly this manner, but we thought that there might be a way to simplify the interface. This new design is an attempt, but it does have tradeoffs. We're exploring a new approach to toolbars which might actually make this less of a problem. I think we can discuss this in more depth once some of those ideas are revealed as well. -Eben

search within results

A very powerful facility of the Google search engine is "search within results". For instance, this allows starting a search with a general category such as "Food". Once one sees *all* the entries thus selected, one can do a 'within' search of "NOT Vegetable". By means of successive elimination, one can quickly narrow down to those entries one is interested in (even though one did not know when one started what the interesting entry would say).

If possible to implement, "search within results" ought to be equally useful for searching the Journal. [A 'Revert' capability is needed, to "back up" in case the most recent 'Search within' did not produce the anticipated result.]

This is an interesting idea. For simplicity in the interface, we opted to omit any explicit facilities for doing this, though it should be mentioned that this is, to a large extent, possible anyway. We have several specific filters which can be applied in different categories, one by one. Each new filter will narrow down the list of results in a meaningful way. Likewise, adding additional search terms to the search field will continue to weed out results (implicit AND). This works relatively well since the list is updated on the fly, unlike Google where an explicit "search again" action is required. This will also improve in the future if we gain support for tokenizing the tags within the search field. Once a tag is typed, it will become a single token, and pressing the erase key once will erase the entire token instead of a single character, which would effectively function as a "go back" option. -Eben

optional alphabetization

Had (build 695) a look in the Journal view at an external storage device:

) The __whole__ display of the objects depends on them having been previously described. There were (among lots of other files) a number of fonts on the device. The best I could do to identify them was to choose the 'text' type, then to search for the string 'font'. But I still had no idea (through Journal view) *what* fonts were on that external device.

If Journal view is going to show objects NOT placed by the child, __something__ needs to be listed (in the view) in case whoever *did* place the object failed to provide an object-description (or meta-data). [Suggestion: show the filename]

Filename should be the default string displayed for any file on a device. If this isn't the case, please enter a ticket in trac and provide a test case for it. -Eben

) The __order__ in which these objects were shown was by "how long ago written". I could care less which fonts were "written" three years ago, as opposed to four years ago.

If, for instance, I was looking to see if "Lucida Grande" was on that external device, it would make my task easier if there was an option to ALPHABETIZE the list (assuming it showed filenames for the listed objects). [Then I could tell if "Lucida Grande" was missing, without having to look at each object in the list.]

I agree, you should be able to click on the What/Who/When Titles of this new design, to order the contents according to them.HoboPrimate 02:22, 2 March 2008 (EST)

Yes, the thin gray bar beneath the main toolbar provides a way to customize the view. This includes being able to sort by "who", "what" and "when". The last of these is the default, since the primary organizational concept of the Journal is time, but any changes to that will persist. -Eben

Better "details" icon ideas

In the main Journal view, the "actions" and "objects" view icons represent the object as being a filled circle or dot. So, a few ideas:

square surrounding the circle could signify taking a closer look at the object.

or a magnifying glass surrounding the circle, but that could clash with the using of magnifying glass for search in sugar

an unfilled circle, so that you are looking through the object, as if it was transparent.

an unfilled circle wih horizontal lines inside, so the object is transparent and showing information inside it.

an unfilled circle with a "teeth-wheel" inside (the icon used by View Source key), signifying taking a closer look at the innards of the object. (this "teeth-wheel could be used elsewhere in the system as well, to always signify taking a inside-look into things, be them activities with Develop, webpages with a html-editor, etc.).

just use text "View Details". HoboPrimate 02:10, 16 March 2008 (EDT)

collections of objects, virtual folders

In the mockups, it shows a Homework object containing 8 objects inside. Is this something like a zipped or tarred object? Or is it a virtual object which links to other objects? Nevertheless, could this be extended to there being virtual containers which hold objects based on tags ? Or better yet, based on tags, search terms and sorting filters? It's the idea of virtual folders which the Journal should really have, to replace and improve typical static ones.HoboPrimate 02:19, 16 March 2008 (EDT)

There are actually two concepts here that we think are different: bundles and "virtual folders" which we've considered in the form of "saved searches". We want to have a Bundle activity which supports "zipped" file formats, allowing one to take any bundle (even activity bundles, content bundles, etc) and open it up to extract all or part of its contents to the Journal. It would also allow a child to put together a bundle of items to send to a friend, upload as a content bundle to a wiki, etc. We'd likely also add a "bundle" button to the Journal, allowing the children to create bundles directly from selections. The saved search approach is more like your virtual folder idea, which would take the search string, filters, and perhaps even view settings and allow the child to give that search a name for future use. -Eben

Date shown for Object

The Journal philosophy is to record each *individual* thing the user works at. But I'm much too lazy to for example 'save' the particulars of each piece of text I look at. So I am satisfied to leave just a single object in the Journal, representing the (composite) activity that in actuality I used to look at a *multiplicity* of texts. The question is how to keep my Journal uncluttered - I don't need more than one object there for any activity used for a *multiplicity* of things.

When I need to again start that (composite) activity -- if I now launch it through the Main view icon, its new object in the Journal will have the current date; but it will take extra effort to delete the previous object from the Journal. If instead I (re)launch it through the existing Journal view entry, its object in the Journal seems to "keep" the original date.

I'm not interested in keeping the previous date when I re-launch an activity used for a *multiplicity* of things. What would really help me in this situation would be an option to 'Resume' that activity, but assign the current date to its object in the Journal.

Enabling the Home View Bulletin board?

Is there anything that can / should be done to enable the ability to post things on the (non-existent) Home View Bulletin board[1]? Marking an entry as a favorite is not the same thing, I assume. So can there be an add-to-bulletin-board button/icon? Disabled/not shown, of course, until the Home View Bulletin board is ready. MartinDengler 22:18, 24 March 2008 (EDT)

Journal-87 impressions

With previous Journal versions, I would click on the little arrow at the right of the entry to (re)launch the corresponding Activity, and click on the icon at the beginning (left) of the entry to call up to the "intermediate" screen (which could be used to enter meta-descriptions). Now these two are reversed - e.g., to (re)launch the Activity, click on its icon in the Journal entry. I agree with this change.

Something I think looks odd is that in Journal-87, that "intermediate" screen has normal-size 'Erase' and 'Resume' icons on the top bar, but a small 'Back' icon (to exit from the "intermediate" screen back to the Journal) on a SEPARATE bar (below the top bar). Why make the 'Back' icon so small? And why put the 'Back' icon on a separate bar of its own?

[The Journal display of the content of a mounted device needs more work. Only a couple of files (as many as the number of entries in the Journal proper? I have a short Journal.) are shown, not a whole screen full. And hovering over the icons in the mounted-device-screen shows the drop-down lists associated with the icons in the Journal proper -- NOT anything to do with the icons on the mounted-device-screen).]

differentiating "favorites"

I finally figured out a good use for the "star" -- to differentiate Activity 'snapshot' entries where the user wants to return to the same place, from entries where the user does *not* intend to resume.

However, it seems simplistic for only a BINARY indicator to be made easily accessible (i.e., to provide merely a "keep"/"don't keep" distinction). Let me suggest that the "star" be actually an entry field. [If the "star" was empty but is clicked on, and nothing is entered, it receives a default "yes" value. If the "star" had a default "yes" and is clicked on, but nothing is entered, the "yes" is erased. Otherwise, what is entered (or deleted) becomes the "star's" content.]

As described in the HIG:Journal, sorting on today's 'binary star' will show "favorites". Sorting on an expanded 'star value' will allow grouping within those "favorites".

This brings up the question -- WHEN will "good" access to the Journal be implemented ??

The wiki talks about being able to 'sort' the Journal entries. As yet I don't see any such capability in the officially released builds. PLEASE, give the users the __capabilities__ the Journal was designed for.

removable-storage-device 'actuators' visually too close to each other

The current design has icons on the bottom bar of the Journal for ("mounted") removable storage devices. When such a device icon is 'clicked' on, the Journal screen shows entries for the content of that device (in place of the content of the normal Journal). When instead such a device icon is 'hovered' on, a palette pops up, with an entry (in the palette) for 'Unmount'.

There is not a large distance between the 'root' of the palette (i.e., the device icon itself) and the 'Unmount' entry in that palette. Yet the __functions__ invoked by those two locations are completely different.

I made a mistake, and happened to click on the palette's 'root' location when I intended to click on its 'Unmount' location. The result was that instead of unmounting the device, the Journal "scanned" the device and showed me (on the Journal screen) the files on that device. Unfortunately, that device happened to contain thousands of files, so it took Journal (running at 100% CPU utilization) several minutes to produce that screen -- in the meantime, my OLPC was responding very little to further user input.

I do not have a solution for the user making a mistake in where he clicks -- but this is an area that ought to be looked at with a view of MINIMIZING the consequences when a user mis-positions the cursor within the palette.

[Note: It is being proposed that another mechanism (than the Journal screen) be used for showing the content of a removable storage device. When such a change gets implemented, this comment would apply to that mechanism.]