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

Sascha Silbe sascha-ml-ui-sugar-devel at silbe.org
Wed Apr 22 04:49:14 EDT 2009


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.

CU Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090422/cd2885d9/attachment-0001.pgp 


More information about the Sugar-devel mailing list