[Sugar-devel] UI mockups for version support in Journal

[Eben Eliason]

On Wed, Apr 22, 2009 at 5:13 AM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> On Wed, Apr 22, 2009 at 10:49, Sascha Silbe
> <sascha-ml-ui-sugar-devel at silbe.org> wrote:
>> On Fri, Apr 17, 2009 at 02:06:55AM +0200, Sascha Silbe wrote:
>>
>> [Mockups]
>>>
>>> The second one [2,3] modifies the date field to be a combo box, like
>>>  shown in Journal Designs #12 [4].
>>
>> The fine thing with mockups is that they show just what you imagine, not the
>> complicated reality.
>>
>> How do we actually handle branches?
>>
>> Option 1:
>> * show all versions in the branch of the current entry, including all
>> ancestors on "super" branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1, 1.1,
>> 1])
>> * rebuild the date/version box on selection of a version
>> + consistency: no matter how you got to the current version, it will always
>> look the same
>> - oneway: once you select a version on a "super" branch, you're stuck to it
>> and can't change back to the originally chosen version anymore.
>>
>> Option 2:
>> * show all versions in the branch of the current entry, including all
>> ancestors on "super" branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1, 1.1,
>> 1])
>> * always show the date/version box of the originally selected version
>> + oneway: you can go back to the originally selected version from any
>> ancestor
>> - consistency: depending on where you entered the tree, you'll get access to
>> different versions.
>>
>> Option 3:
>> * only show direct linear ancestors, not "super" branches
>> + no consistency or oneway issues
>> - no access to earlier branches, i.e. any load+save of a non-HEAD version
>> will cut the entire ancestry for the just saved version
>>
>> Option 4:
>> * flatten and sort the entire version tree according to the date
>> + no consistency or oneway issues
>> + access to all branches/versions
>> - no information about ancestry, an intermediate version might lack content
>> that both "neighbors" (in the list) have
>>
>>
>> Thinking about it, Option 4 is probably the way to go for now (unless
>> someone can come up with a smart #5). Rely on the user to tag the documents
>> well enough to avoid confusion. We probably want to revise this decision
>> later when we got some experience with actual user behaviour.
>
> #2 doesn't sound too bad to me.

I agree, I think #2 is a good option. I understand the confusion with
the inability to show descendants of a given entry, but in practice
versioning in Sugar (I expect) will be used more like a history of
changes than a full version tree. Merging would complicate this (we
can cross that bridge if/when we support it), but until then we always
know the full ancestry of a given node as a single ordered path. This
history (and not future) of a specific entry is likely of most
importance in the context of a Journal which is meant to as a record
of the past.

One other note on this idea. Technically, we would be able to show
*some* "future" (newer) versions for a given entry...we can show all
descendants up until a branch unambiguously. I'm not sure which
approach (ancestors only, or ancestors plus un-branching descendants)
is the better course.

Finally, just for fun, let me offer an option 5...

Option 5:
* show all versions in the branch of the current entry (including all
descendants prior to a branch), including all ancestors on "super"
branches (i.e. 1.1.3 shows [1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1, 1])
* set apart by a separator line at the top of the version menu, show
all n children at the first branch in the tree.
+ you can get to any point in the tree from any other point
+ the tree is reduced to a manageable list at every step, which shows
ancestor history for the current entry and a single "choice" at the
first branch in the tree.
- if you navigate to an ancestor, it might not be obvious how to get
back to where you started (if there were intermediate branches).
- perhaps this exposes too much, making the system more complicated.

Food for thought.

Eben

> Regards,
>
> Tomeu
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>