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

[Tomeu Vizoso]

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.

Regards,

Tomeu